GDPR-Compliant Guest WiFi: A Practical Checklist

E very guest who connects to your WiFi hands you something: a device address, a login identifier, a timestamp, a quota counter. None of it is a surprise, and none of it is automatically a problem. The problem starts when the data is collected without a purpose, kept longer than it should be, or stored on somebody else's server when your legal basis requires it to stay with you.
The good news is that a captive portal is one of the easiest places to build compliance into, because the login page is a place where you already talk to the user. The bad news is that most operators treat the portal as a network device and leave the legal work to a policy document nobody reads. Here is a checklist that closes the gap.
1. Decide what the portal actually collects
Start with the smallest set of fields that lets the network run. For a guest network you usually need a login identifier, the timestamp of the session, the profile the session runs under, and traffic counters. You do not need a full identity to hand out bandwidth.
* Write down every field the portal stores, one per line. If a field is not on the list, it should not be in the database.
* Separate technical identifiers from personal data. A MAC address is an identifier; a name attached to it is personal data.
* Decide explicitly whether the login form collects a name, an email address or only a voucher code. Each additional field is additional justification you have to be able to defend.
2. Keep the data on premises
This is the single biggest lever you have, and it is the reason an on-premises captive portal is a compliance decision as much as an architectural one. When guest records live on the unit inside your building, there is no third-party processor to appoint, no cross-border transfer to document and no vendor sub-processor list to keep current. The controller and the processor are the same organisation, in the same legal jurisdiction, on hardware you can account for.
An on-premises platform such as WifiGem keeps the user database on the appliance itself, assigns addresses locally and enforces quotas locally. When someone asks who holds your guest data, the answer is a short one: you do.
3. Make consent specific, and make it a real choice
A login page that says “by connecting you accept our terms” and links to a PDF is weak consent at best. Consent has to be specific per purpose and it has to be as easy to refuse as to accept.
* Present each purpose separately: network access, optional marketing, optional usage analytics.
* Make the optional ones genuinely optional. If a guest can reach the internet without ticking a marketing box, the tick means something.
* Record the version of the notice and the timestamp of the decision. You cannot prove what somebody agreed to if you cannot show what was on screen at the time.
* Never pre-tick a consent box.
4. Set a retention period and enforce it automatically
The data you cannot delete is the data you cannot defend. Decide how long you need each category of record — session data, accounting records, login history — and make the system delete it for you.
This is where automation pays for itself. A platform with configurable, automatic data cleanup removes expired guest records on a schedule instead of relying on somebody to run a deletion job before an audit. The rule becomes a configuration value rather than a habit.
5. Keep access logs, and make them tamper-evident
Accountability requires that you can show who accessed what and when — including your own administrators. Retain an audit trail of administrative actions: profile changes, forced disconnections, configuration edits, exports. In a multi-operator setup, granular access control over those operations is what keeps the trail meaningful.
6. Build in the right to be forgotten
A guest who asks to be removed should not need to write to three addresses. Design the deletion path before you need it: identify the records tied to a given identifier, decide what has to be kept for legal or accounting reasons, and delete the rest. Where a record must be retained, be able to explain why in one sentence.
7. Handle the edge cases on purpose
* Shared devices and family members: give the session an owner, but make the retention rule apply to the owner, not to whoever uses the phone afterwards.
* Payment-card data: keep it out of the portal entirely. If a guest is paying, hand them to a payment provider rather than storing card numbers yourself.
* Minor guests and unaccompanied children: define an age policy and a logging behaviour for it in advance.
* Offboarding: when a staff member or a contractor leaves, remove their operator account and their access to the logs, not just their password.
A short version to keep in the operations room
Minimise the fields, keep the data on your own hardware, separate the consents, automate the retention, log the administrators, and rehearse the deletion. Six items, all of them configuration or process rather than a rewrite. Compliance is mostly the discipline of deciding things in advance instead of discovering them during an enquiry.

No part of this document may be reproduced without prior written permission of WifiGem.