In brief
On day 730 the record is deleted from the box and the deletion is written to the audit trail. How retention, the duty to destroy and guest requests fit on one calendar.
Two duties, one calendar
A guest Wi-Fi record sits at the intersection of two sets of rules. Law 5651 expects a public-access provider to keep internal IP assignment records for a set period. KVKK, the Turkish data protection law, expects a data controller not to keep personal data longer than the purpose requires, and to delete or destroy it when the period ends.
At first glance they seem to conflict: one says "keep", the other "do not forget to delete". In fact they are two ends of the same calendar. The record stays for the retention period; on the day the period ends, it must go. The trouble starts when both points are left to human memory. Hotspot-Box hands that calendar to the box.
What happens on day 730?
The box keeps each day's records as a separate day. Every day has an age. A day older than 730 days is deleted from the box automatically. You press no button; you wake up and the oldest day is gone.
The deletion is not silent. It is written to the audit trail with: which day was deleted, when, and which rule triggered it. That entry does not contain the deleted data itself; it records only the deletion event.
Why does this matter so much? Because an inspection brings two questions: "Do you keep the records?" and "Do you delete expired ones?". The archive list answers the first; the deletion entries in the audit trail answer the second. You have more than "we deleted it": a record of when and what.
Deletion, destruction, anonymisation
Three terms sit side by side in KVKK language. Briefly:
| Term | Meaning | In the box |
|---|---|---|
| Deletion | Data becomes inaccessible to the relevant users | The day is removed from the box after day 730 |
| Destruction | Data cannot be recovered in any form | Deleting the copies outside the box is your process |
| Anonymisation | Data can no longer be matched to a person | The anonymisation option in guest request handling |
Note the third row. The box deletes the day on its own disk; the same day in your SFTP copy and your offline ZIPs is your responsibility. If you keep copies under the 3-2-1 rule, add those copies to your destruction calendar. The practical approach: a 730-day automatic clean-up on the SFTP target and an annual review of offline ZIPs.
What should the destruction policy say?
KVKK expects a data controller to document its retention and destruction processes. For guest Wi-Fi, one paragraph is enough. It should cover:
- Which data: device MAC, internal IP, session times, verification detail (encrypted phone, coupon, e-mail).
- Why: the record-keeping duty under Law 5651.
- How long: 730 days.
- How it is deleted: automatically in the box, recorded in the audit trail; for copies, as follows.
- Who is responsible: name and title.
Keep that paragraph consistent with the box's panel. Being caught with 730 in the policy and a different value in the panel is worse than being caught without a policy.
When a guest makes a request
KVKK grants your guests certain rights: to learn whether their data is processed, to request information, correction or deletion. What happens when a guest says "what do you hold on me, delete it"?
The Hotspot-Box panel includes KVKK request (DSAR) management. The flow:
- Log the request. Date, the requester's verification detail, type of request. Do not act before confirming the requester actually owns that number; an SMS code is enough for this.
- Find the records. The panel lists the sessions tied to the given verification detail. Because phone numbers are stored encrypted, the search runs through the panel and the authorised role sees the result masked.
- Act according to the request.
- Information request: State in writing on which dates sessions were opened and by which method. Sites visited are not kept; say so.
- Deletion request: For records still within the retention period, the record-keeping duty generally takes precedence. In that case you reply explaining that the data will be kept for the legal retention period and deleted automatically at its end. Expired records no longer exist. Get legal advice here; there may be edge cases.
- Anonymisation: For fields outside the legal retention scope (for example an e-mail collected with marketing consent), anonymisation can be used from the panel.
- Record the reply. Add the reply date and content to the request entry. The response deadline is set by regulation; start the clock on the day the request arrived.
Every step is written to the audit trail, so a year later the answer to "what did we do with that request" is in the panel.
The platform side: guest data never reaches us
A frequent question: "Do the records also go to you? Are you a processor too?" No. The box sends the SMS directly to your provider; hotspot-box.com only supplies the API details and counts credits. Guest numbers, message content and session records never reach the platform. Device telemetry (disk, timestamp status, credit) contains no guest data. You are the data controller, and the records stay with you.
Short checklist
- Does the panel show a retention period of 730 days?
- Are there recent deletion entries in the audit trail? (Not yet if the box is under two years old; that is normal.)
- Is a destruction schedule defined for the SFTP target and offline copies?
- Does your destruction policy match the panel?
- Is the last KVKK request logged and closed in the panel?
See the FAQ for more on KVKK and record retention, or the contact page for a pre-installation call.
This article is general information and is not legal advice.
This article is for information only and is not legal advice; confirm your obligations with your legal adviser.