This Data Retention Schedule lists how long ChefSphere OÜ ("ChefSphere") keeps each category of personal and operational data, on what legal basis, and through what mechanism the data is removed at the end of its retention window. It is published under Art. 5(1)(e) GDPR (storage limitation) and under the transparency obligations of Arts. 12–14 GDPR. It supplements the Privacy Policy §7 — where a retention window is described in prose — and supersedes any conflicting statement made in a prior policy version for new processing from the effective date.
| Column | Meaning |
|---|
| Dataset | The personal or operational data held, described at a granularity meaningful to a data subject. |
| Legal basis for the retention | The statutory or contractual rule that authorises retention for the stated period. |
| Retention | The active retention window on production systems. |
| Deletion mechanism | How data is removed: scheduled job, policy-driven purge, manual deletion, anonymisation, or contractually-mandated destruction by a processor. |
| Exception | Any rule that extends or truncates the default retention (for example a legal hold, an open investigation, a user-initiated account deletion). |
All retention windows are maximums. Data is deleted as soon as it is no longer needed for the original purpose, even before the maximum is reached.
| Dataset | Legal basis | Retention | Deletion mechanism | Exception |
|---|
| Email, password hash (bcrypt), display name, age band, language, timezone, verification status | Art. 6(1)(b) GDPR (contract) | Life of the account + 12 months after closure | Nightly deletion job for closed-account records past the grace window | Records subject to an open legal claim are placed on legal hold and excluded from the job until release |
| Two-factor authentication settings (TOTP secret, recovery codes hash) | Art. 6(1)(b) + 6(1)(f) (security) | Life of the account | Removed synchronously on 2FA disable | — |
| Authentication identifiers from Google, Facebook, Apple sign-in | Art. 6(1)(b) | Life of the account + 12 months after closure | Nightly deletion job | — |
| Active and expired device / session records | Art. 6(1)(f) (security) | 90 days rolling | Daily truncation job | — |
| Identity-verification results (seller / author KYC) | Art. 6(1)(c) (AML / KYC) | 5 years after the last marketplace transaction | Scheduled purge post-AML retention | Raw ID document is not stored — only pass/fail and a reference ID held by Stripe |
| Dataset | Legal basis | Retention | Deletion mechanism | Exception |
|---|
| Posts, recipes, comments, reactions, follow graph | Art. 6(1)(b) (contract) | Life of the account + standard operational purge window after deletion (≤ 30 days for production; ≤ 90 days for index purge) | User-initiated delete + scheduled post-account-closure purge | Content under an open DSA Art. 16 notice is preserved for the notice-and-action cycle |
| Direct messages, group messages | Art. 6(1)(b) | Life of the conversation; on account closure, messages visible to the other participant persist until they delete their side, then removed on both sides | Per-message soft-delete then hard-delete 30 days after both sides soft-deleted | — |
| Ebook reader data (bookmarks, highlights, reading progress) | Art. 6(1)(b) | Life of the account | User-initiated delete | — |
| Community prices, reviews, ratings | Art. 6(1)(b) | Life of the account; anonymised aggregates may persist after the account is closed to preserve marketplace integrity | Per-item delete + anonymisation of underlying aggregates | Reviews tied to a completed transaction persist with the transaction record |
| Dataset | Legal basis | Retention | Deletion mechanism | Exception |
|---|
| Nutrition targets, intake, water, sleep, workout entries | Explicit consent — Art. 9(2)(a) | Life of the feature being enabled; deleted within 30 days of withdrawal of consent | Withdraw-consent action triggers purge job immediately | Backups roll off within 30 days |
| AI health-feature context (profile dietary preferences used for ranking recipes) | Explicit consent — Art. 9(2)(a) | Same as above | Same as above | — |
| Dataset | Legal basis | Retention | Deletion mechanism | Exception |
|---|
| AI Chef conversation history (user side) | Art. 6(1)(b) | Life of the account; user-initiated clear button purges immediately | User-initiated clear | — |
| AI prompts and outputs sent to provider | Art. 6(1)(b) + contractual no-training clause with provider | Provider-side: up to 30 days for safety review then deleted, per provider contract; ChefSphere side mirrors the user chat history | Provider's retention policy enforces on their side | Abuse-investigation may extend up to 180 days |
| AI generation artefacts for Art. 50(4) deepfake labelling | Art. 6(1)(c) (AI Act compliance) | 24 months | Scheduled purge job | — |
| Dataset | Legal basis | Retention | Deletion mechanism | Exception |
|---|
| Invoices, receipts, chargebacks, refunds, tax records, order history | Art. 6(1)(c) — Estonian Accounting Act (Raamatupidamise seadus §12) | 10 years from end of financial year | Annual rollover job; anonymised after retention if operationally needed | — |
| Payment-method references (last 4, brand, billing country) | Art. 6(1)(b) / 6(1)(c) | Life of the account; removed from active table on account closure, kept on invoice for 10 years | Scheduled purge | — |
| DAC7 seller reports | Art. 6(1)(c) — Directive (EU) 2021/514 | 10 years | Scheduled purge | — |
| VAT / OSS remittance records | Art. 6(1)(c) — Council Directive 2006/112/EC as implemented in EE | 10 years | Scheduled purge | — |
| Dataset | Legal basis | Retention | Deletion mechanism | Exception |
|---|
| Order records, rental records, shipping tracking | Art. 6(1)(b) | 10 years (invoice obligation) — then anonymised | Annual rollover | Records under an open dispute are retained until resolution |
| Listing photos, videos, descriptions | Art. 6(1)(b) | Life of the listing + 30 days post-removal for audit evidence | Scheduled purge | — |
| GPSR traceability records (technical documentation, instructions, safety warnings per Art. 9(2) GPSR) | Art. 6(1)(c) — Reg. (EU) 2023/988 | 10 years from date the product was placed on the market | Scheduled purge | — |
| Marketplace chat, meet-up evidence (photos, timestamps) | Art. 6(1)(b) + 6(1)(f) | 3 years default; up to 10 years where a GPSR incident or dispute is open | Scheduled purge | Open-dispute exception |
| Dataset | Legal basis | Retention | Deletion mechanism | Exception |
|---|
| Moderation decisions, DSA Statements of Reasons | Art. 6(1)(c) — Reg. (EU) 2022/2065 Arts. 17 + 24(5) | 3 years (default); 5 years for serious cases; DSA Transparency Database submissions retained indefinitely in aggregate | Scheduled purge; aggregate summaries retained for the annual report | — |
| Abuse reports received at [email protected] | Art. 6(1)(c) + 6(1)(f) | 2 years | Scheduled purge | Open-case exception |
| DMCA / CDSM takedown records, counter-notices | Art. 6(1)(c) — 17 U.S.C. §512 + Reg. (EU) 2022/2065 | 3 years; repeat-infringer register kept for the life of the policy window | Scheduled purge | — |
| Suspensions under Art. 23 DSA | Art. 6(1)(c) | 2 years | Scheduled purge | — |
| Dataset | Legal basis | Retention | Deletion mechanism | Exception |
|---|
| Access logs (web, API, mobile) | Art. 6(1)(f) — security | 90 days on hot storage, 365 days on cold storage | Tiered-storage retention policy | Incident-response extension up to 7 years if a breach is under investigation |
| Web Application Firewall and DDoS logs | Art. 6(1)(f) | 90 days rolling | WAF provider purge | — |
| Crash reports, stack traces, performance traces | Art. 6(1)(f) | 90 days | Provider purge | — |
| Security audit trail (privileged operations by ChefSphere staff) | Art. 6(1)(c) + 6(1)(f) | 7 years | Immutable append-only store; scheduled archival | — |
| Two-factor authentication attempts, password resets, sign-in events | Art. 6(1)(f) | 365 days | Scheduled purge | — |
| Dataset | Legal basis | Retention | Deletion mechanism | Exception |
|---|
| Support tickets and email threads with users | Art. 6(1)(b) | 3 years from closure | Scheduled purge | Open-claim exception |
| Legal and authority correspondence | Art. 6(1)(c) | 7 years (Estonian administrative-law default) | Immutable archival with scheduled purge | — |
| Marketing consent records and history | Art. 6(1)(c) — evidential purpose | 3 years after consent withdrawal | Scheduled purge | — |
| Transactional emails (billing, security, password resets) | Art. 6(1)(b) | 2 years | Provider purge | — |
- Production databases are backed up using a combination of continuous write-ahead-log streaming and periodic snapshots.
- Rolling backup retention is 30 days. A record that is deleted in production is overwritten in backups within 30 days.
- Long-term archival snapshots (where taken for disaster-recovery) are encrypted with a separate key and retained for a maximum of 180 days before deletion; no long-term personal-data retention sits in backups only.
If ChefSphere is served with a preservation order, a court subpoena, an MLAT, or becomes aware of a reasonably foreseeable litigation, the dataset covered by the hold is excluded from the deletion jobs in this schedule until the hold is released. Holds are administered by the Law Enforcement Response Team and documented in the audit trail at §9.
A data subject can request confirmation that retention windows have been applied to their data, through the mechanisms in the Privacy Policy §9 (in-app Privacy Controls, authenticated API, or email to [email protected]). The DSAR pipeline returns a copy of personal data that is still held together with the retention window that applies to each category.
Where a dataset is removed through anonymisation rather than hard deletion, the result is irreversible: the anonymised record can no longer be linked back to an identifiable natural person without additional information we do not hold and will not obtain. Anonymisation is used primarily for analytics signals, marketplace aggregates, and research datasets. Personal data is always deleted (not anonymised) unless anonymisation is expressly preferable for the purpose.
We update this schedule when a retention rule changes — whether because of law, operational learning, a new feature, or the end of a legacy processing activity. Changes take effect at the effective date shown in the header; prior versions are available on request at [email protected].