1. Core Principles
- Bokko only retains personal data for as long as necessary for the specific purpose.
- Retention rules follow service delivery, security, and enforcement requirements.
- Bokko implements retention through system-level automated processes where available; otherwise, administrative or periodic purge processes are used.
2. Retention Schedule
| Data Category | Retention Period | Rule |
|---|---|---|
| Service Provider account data | During the term of the contract, then 90 days | Deleted or anonymized after the export and recovery window. |
| Service Provider profile and configuration | During the term of the contract, then 90 days | Retained only for a temporary transition period after termination. |
| Guest booking records | 60 months (5 years) | From appointment date or final status update. Based on general statutory limitation periods. |
| Booking event logs | 60 months (5 years) | Deleted along with the associated booking. |
| Guest profile and phone index | 60 months (5 years) from last activity | Synchronized with guest document deletion. No independent TTL. |
| Waitlist subscription data | Until salon-configured expiry (1–90 days, default: 30) | Automatically deleted by scheduled function upon expiry. |
| Guest response tokens | Until booking closure, or max 30 days after | Deleted or nulled after the matter is closed. |
| SMS and email delivery metadata | 12 months | Deleted after the delivery accountability period. |
| Review request email audit (task) log | 3 months from creation (createdAt) |
Operational audit and debugging purpose. NOT used for the 90-day frequency cap calculation — that lives on the guest record reviewRequestLastSentAt field. Automatically purged after 3 months by the purgeExpiredData scheduled job. |
| Rate limiting and security data | 12 months | May be extended during active incidents. |
| Customer communication (emails, support tickets) | 7 years | Based on legitimate interest for accountability and enforcement. |
| Internal admin notes for profiles | 7 years | Restricted to platform admin access; for operational accountability. |
| Legal enforcement communication | 5 years from case closure | Retained for contractual or legal claims. |
| Billing and accounting records | At least 8 years | Mandatory retention under Hungarian accounting laws. Independent controller purpose. |
| Admin and security audit logs | 7 years | Based on legal enforcement and security obligations. |
| Data export audit records & temp files | Until signed URL expiry | Temporary storage for compliance exports; deleted via TTL. |
| Lifecycle and system event logs | 6 months | For operational and incident investigation; automated purge. |
| Staff invitations | 30 days from expiry or acceptance | Automatically deleted for email PII cleanup. |
| Staff profile PII (name, email) after deletion or anonymisation | Anonymisation immediate on PII fields; audit log entry 7 years | For cases handled by the anonymize_staff_member (PII cleanup), remove_member, and unlink_staff callables, Bokko immediately anonymises the profile PII fields (name, email) and records the operation in the 7-year admin audit log. Booking history is retained in anonymised form for statistical and accounting-record consistency purposes. |
| Provider-uploaded images (avatar, hero, logo, gallery) and derived image variants | For the duration of the contract; deleted alongside the 30-day export window after regular termination | Storage triggers automatically generate variants (thumbnails) that are also deleted when the source asset is deleted. „Forward-orphan" cases (object without a Firestore reference) are reconciled by the scheduled cleanupOrphanedStorageRefs job. |
| Newsletter recipient snapshot and consent audit log | Recipient snapshot: 24 months from send; consent audit: 5 years | The recipient list snapshot captured at send time is retained for 24 months to handle delivery complaints; the double opt-in consent change audit log is retained for 5 years for the demonstrability purpose referenced in Section 3a. |
| Marketing withdrawal (suppression) record | 5 years from withdrawal | Durable evidence of the withdrawal of marketing consent (legal and demonstrability purpose, GDPR Art. 7(1) accountability). The record is minimal and data-frugal: instead of the withdrawn email address, it stores its non-reversible cryptographic fingerprint (identity HMAC), the timestamp of the withdrawal, the source, the provider identifier, and the retention deadline. It contains no free-text guest data or plaintext email. This record is what enables a later new booking not to automatically revive newsletter sending without the guest's renewed, explicit consent; the record also survives a possible anonymisation (it is not personal data). |
| Anonymised guest profile lifecycle marker (privacy shell) | Permanent (contains no personal data) | When a guest profile is anonymised via the guest data-management portal ("My Data", see Privacy Policy Section 6a) or by controller-initiated erasure, a non-personal, technical lifecycle marker remains (state, operation identifier, timestamps — without name/email/phone). Its purpose is to preserve the integrity of references to past bookings and the auditability of the erasure. This marker is not personal data, cannot be used to rebuild the guest profile, and does not appear on normal product surfaces. |
| Encrypted recovery staging (privacy purge staging) | Short, limited recovery window, then automatic final erasure | During the two-stage anonymisation, the operational identity is temporarily stored encrypted and isolated for a short recovery window (to allow reversibility of an erroneous request, or one not initiated by the guest — operational-identity scope only, not a full historical restoration). When the window expires, the staging record is automatically and permanently erased. The content of the staging is itself personal data, and is therefore retained for the shortest possible time. |
| Guest data-management request record (privacy request orchestration) | For the duration of the adjudication of the request and of statutory demonstrability | The execution/audit record of a data-subject request received through the portal. Data-frugal: it stores frozen, technical identifiers for identifying the request (provider and profile identifier, identity generation), and contains no plaintext email, name, phone number, or retrievable raw input stored for convenience. The magic-link tokens used for authentication are single-use and short-lived. |
| Subscription lifecycle and refund metadata (subscription doc, Stripe metadata) | For the duration of the contract + 8 years from termination | The subscription doc contains the firstPaid* fields (amount, currency, Stripe invoice.status_transitions.paid_at), the 30-day refund window state, and the refund saga lifecycle metadata. The 8-year retention follows the accounting obligation (Hungarian Accounting Act § 169). |
| Terminated (archive_readonly) salon dataset (booking history, profile, images, configuration) | Retained until reactivation is possible; not automatically purged together with the 30-day export window from termination | Upon termination (Stripe customer.subscription.deleted), the salon enters accountMode = 'archive_readonly'; in this state the dataset is retained in read-only form so the provider can resume the subscription with the existing data in a later reactivation window (create_reactivation_checkout_session). During Open Beta, no automatic archive_readonly purge job runs; an explicit phase-out schedule and data-subject notification will be introduced before GA cutover (see internal rule feedback_archive_readonly_no_auto_purge). |
| Outbound webhook delivery and retry log | 12 months from delivery or terminal exhaustion state | Delivery metadata of webhook events sent from Bokko to third-party downstream systems (status, retry count, exhaustion state) — for debug and complaint handling purposes. Details in Terms of Service Section 15. |
3. Deletion Rules
- Booking-related event logs and derived guest indexes are deleted in coordination.
- Response tokens are deleted or nulled after use or case closure.
- Bokko uses scheduled cleanup tasks for system-wide execution of the retention policy.
- Anonymisation initiated through the guest data-management portal is two-stage: immediate access restriction, followed by final erasure after a short, encrypted recovery window. The process covers only operational personal data not subject to statutory retention; records that must be retained by law remain, segregated.
Backups and residual data. Personal data deleted from the operational system
may still be temporarily present in the automatic backups — Point-in-Time Recovery (7 days),
daily backup (14-day retention) and weekly backup (84-day retention), see
DPA Section 14 — after the erasure is
executed, until the relevant backup retention period expires. Residual data in the backup layer
is access-restricted, serves solely a disaster-recovery purpose, and is not restored or surfaced
on product surfaces during normal operation. When the backup retention cycle expires, the
residual data ceases to exist as well. Vendor-side (Billingo, Számlázz.hu, Stripe, Barion,
SimplePay) retained records and transaction records remain under the respective provider's own
retention policy.
4. Data Subject Requests
Requests regarding guest booking data are handled by Bokko according to instructions from the relevant service provider, as the provider is the data controller. For Bokko's independent purposes, Bokko acts directly.
5. Review
This document is reviewed at least annually, or upon introduction of new data flows, providers, or legal requirements.