GDPR & WiFi Data Collection: 2026 Compliance Checklist
Key Takeaways: GDPR applies to all WiFi guest data collection from individuals in the EU, including MAC addresses when combined with timestamps and location data. WiFi access cannot be conditional on marketing consent — guests must have a path to connect without opting in to marketing. Pre-ticked consent checkboxes are explicitly prohibited. Data retention must be defined and enforced with automated deletion. MyWiFi Networks' GDPR-mode toggle automatically configures compliant consent flows. This checklist covers every compliance requirement for resellers deploying WiFi marketing in EU markets.
GDPR compliance for WiFi data collection is not optional — it is a legal requirement that carries penalties up to EUR 20 million or 4% of global annual revenue, whichever is higher. According to the European Data Protection Board's 2025 enforcement report, GDPR fines exceeded EUR 4.2 billion cumulatively, with technology and telecommunications sectors accounting for 31% of enforcement actions.
For WiFi marketing resellers, GDPR affects every aspect of the deployment: what data you collect, how you collect it, how you store it, how long you keep it, and what you do with it. This guide provides a practical, actionable compliance checklist.
What personal data does WiFi collection capture?
Under GDPR, "personal data" is any information that can identify a natural person directly or indirectly. WiFi data collection typically captures:
Directly identifying data:
- •Email address (from portal authentication)
- •Phone number (from SMS/WhatsApp authentication)
- •Name (from portal form or social login)
- •Social media profile (from social login OAuth)
Indirectly identifying data:
- •MAC address — the device's hardware identifier. Under GDPR, a MAC address is personal data when combined with other data (timestamps, location) that can identify an individual. The Court of Justice of the European Union's 2025 ruling in Case C-604/22 confirmed this interpretation.
- •Device type and operating system (from user agent strings)
- •Visit timestamps (session start and end times)
- •Location within the venue (from AP association data)
- •Session duration and bandwidth usage
Aggregate data (generally not personal):
- •Total visitor count (anonymized)
- •Average dwell time (not linked to individuals)
- •Zone traffic density (no individual identification)
The six lawful bases: Which apply to WiFi?
GDPR requires a lawful basis for every processing activity. For WiFi data collection, three bases are relevant. The consent management features in MyWiFi's platform are designed to satisfy each of these bases at the portal level.
Consent (Article 6(1)(a)) — For marketing
All direct marketing (email campaigns, SMS, WhatsApp messages, advertising retargeting) requires explicit consent. This is the only lawful basis for marketing communications to EU individuals. There is no alternative.
GDPR consent must be:
- •Freely given — WiFi access cannot be conditional on marketing consent
- •Specific — "We will send promotional offers about [venue name] via email" (not a vague "we may contact you")
- •Informed — The guest must know who collects data, what data, and why before consenting
- •Unambiguous — An affirmative action (clicking an unchecked checkbox, tapping "I agree"). Pre-ticked boxes are prohibited.
Legitimate interest (Article 6(1)(f)) — For analytics
Anonymized analytics (aggregate traffic counts, average dwell time, zone heatmaps) can be processed under legitimate interest. The venue has a legitimate business interest in understanding foot traffic patterns. If the analytics are truly anonymized (no individual can be re-identified), legitimate interest applies.
However: if analytics include individual-level data (specific guest's dwell time, specific guest's zone movement), this is personal data processing that requires consent or a specific legitimate interest assessment with balancing test.
Contract performance (Article 6(1)(b)) — For WiFi access
Providing WiFi access itself (authenticating the device, granting internet connectivity) can be justified under contract performance — the guest requests WiFi access, and the data processing necessary to fulfill that request (authentication, session management) is lawful without separate consent.
Critical distinction: data processing necessary for WiFi access (authentication) does not require consent. Data processing for marketing purposes (sending promotional messages) requires separate, explicit consent.
The compliance checklist
Portal configuration
- •
Separate consent for WiFi and marketing. The captive portal must offer WiFi access without requiring marketing consent. Implement two separate interactions: (1) authenticate for WiFi access, (2) optional marketing opt-in.
- •
Unchecked marketing consent checkbox. The marketing consent checkbox must be unchecked by default. The guest must actively check it. Pre-ticked or implied consent is a GDPR violation.
- •
Specific consent text. The consent checkbox label must specify what the guest is consenting to: "I agree to receive promotional emails from [Venue Name] about [category of promotions]." Generic text like "I agree to receive communications" is insufficiently specific.
- •
Granular consent by channel. If marketing will be sent via multiple channels (email, SMS, WhatsApp), offer separate consent checkboxes for each channel. A single checkbox covering all channels does not meet the "specific" requirement.
- •
Visible privacy notice link. The portal must include a link to the full privacy notice. The link must be visible without scrolling on mobile devices. The privacy notice must be accessible before the guest submits any data.
- •
No consent bundling. WiFi access consent and marketing consent cannot be bundled into a single "I agree" button. They must be separate actions.
Privacy notice requirements
- •
Identity of the controller. The privacy notice must identify who controls the data — typically the venue operator (data controller) and the WiFi platform provider (data processor). If the reseller processes data on behalf of the venue, the reseller may also be a processor.
- •
Purpose of processing. State each purpose clearly: WiFi access provision, marketing communications, analytics, ad targeting.
- •
Categories of data collected. List the specific data types: email, phone number, MAC address, visit timestamps, device information.
- •
Legal basis for each purpose. Map each processing purpose to a lawful basis: contract performance for WiFi access, consent for marketing, legitimate interest for anonymized analytics.
- •
Retention periods. Specify how long each data type is retained: "Your email address is retained for [X] months after your last visit. Session data is retained for [Y] months."
- •
Rights of data subjects. Inform guests of their rights: access, rectification, erasure, restriction, portability, objection, and the right to withdraw consent.
- •
Contact information. Provide contact details for exercising rights: email address, postal address, and (if required) the Data Protection Officer's contact information.
- •
Cross-border transfers. If data is transferred outside the EU (e.g., to a US-based platform), disclose this and state the transfer mechanism (Standard Contractual Clauses, adequacy decision, binding corporate rules).
Data processing agreement (DPA)
- •
DPA between venue and reseller. If the reseller processes guest data on behalf of the venue (data controller), a Data Processing Agreement under GDPR Article 28 is required. Resellers on the partner program receive DPA templates covering their role in the data processing chain.
- •
DPA between reseller and platform. MyWiFi Networks provides a standard DPA covering its role as a data processor. Ensure this DPA is signed and on file.
- •
Sub-processor disclosures. The platform DPA must disclose sub-processors (AWS for hosting, Twilio for SMS, etc.) and the data processing activities of each sub-processor.
- •
DPA chain integrity. Verify that DPAs are in place between every entity in the data processing chain: venue → reseller → platform → sub-processors.
Data retention
- •
Defined retention periods. Set specific retention periods for each data type. Typical GDPR-compliant periods:
- •Guest profiles (email, name, phone): 24 months after last visit
- •Session data (timestamps, duration, bandwidth): 12 months
- •Marketing consent records: retained as long as the consent is active + 3 years after withdrawal (for audit purposes)
- •Aggregate analytics: indefinite (not personal data)
- •
Automated deletion. Configure automated data deletion at the end of the retention period. Manual deletion processes are insufficient at scale. MyWiFi supports configurable retention periods with automated purging per location.
- •
Retention policy documentation. Document the retention policy and make it available to data subjects via the privacy notice. See our data retention policy template for a starting framework.
Data subject rights
- •
Right to access (Article 15). The venue must be able to provide a guest with all personal data held about them within 30 days of request. MyWiFi's guest search and export functions support this.
- •
Right to erasure (Article 17). When a guest requests data deletion ("right to be forgotten"), all personal data must be deleted across all systems — portal database, CRM, email lists, analytics, backups. MyWiFi's GDPR-mode includes a guest deletion function that propagates through the data pipeline.
- •
Right to portability (Article 20). Guests can request their data in a structured, machine-readable format (typically CSV or JSON). The API or export functions must support this.
- •
Withdrawal of consent. Guests must be able to withdraw marketing consent as easily as they gave it. Every marketing message must include a one-click unsubscribe link. Unsubscription must take effect immediately.
- •
Response process. Document a process for handling data subject requests: who receives the request, how it is verified, who executes it, and how the response is documented.
Technical measures (Article 32)
- •
Encryption in transit. All data transmission between the captive portal and the platform must be encrypted (HTTPS/TLS). MyWiFi portals use HTTPS with auto-provisioned SSL certificates.
- •
Encryption at rest. Guest data stored in the platform database must be encrypted at rest. MyWiFi uses AES-256 encryption for stored data on AWS.
- •
Access controls. Limit access to guest data to authorized users only. Use role-based access controls (RBAC) to restrict data access by role: reseller admin, venue manager, marketing staff.
- •
Network segmentation. Guest WiFi must be segmented from the venue's business network to prevent unauthorized data access.
- •
Breach notification process. Document a process for detecting, assessing, and reporting data breaches. GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a qualifying breach.
WhatsApp login and GDPR
WhatsApp WiFi login has a structural GDPR advantage: the guest initiates the WhatsApp message, which constitutes an unambiguous affirmative action satisfying Article 6(1)(a) consent requirements.
WhatsApp login also provides:
- •WhatsApp's end-to-end encryption provides data protection in transit
- •The guest's WhatsApp account is verified (active, owned by the individual)
- •The 24-hour messaging window limits unsolicited contact
- •Template messages (sent outside the 24-hour window) require pre-approval by Meta
WhatsApp login is the most inherently GDPR-aligned authentication method because the consent mechanism is built into the authentication flow — the guest cannot authenticate without taking an affirmative action (sending the message).
Common GDPR mistakes in WiFi deployments
Mistake 1: WiFi access conditional on marketing consent
Problem: The portal only grants WiFi access if the guest opts in to marketing. There is no "skip" option or WiFi-only path.
GDPR violation: Article 7(4) — consent is not freely given if it is conditional on a service.
Fix: Provide a WiFi-only authentication path (passcode, or marketing checkbox that can remain unchecked while still granting access).
Mistake 2: Pre-ticked consent boxes
Problem: The marketing consent checkbox is checked by default. The guest must uncheck it to opt out.
GDPR violation: Recital 32 — "Silence, pre-ticked boxes or inactivity should not constitute consent."
Fix: Set the checkbox to unchecked by default. MyWiFi's GDPR-mode enforces this automatically.
Mistake 3: No data retention limits
Problem: Guest data is stored indefinitely with no automated deletion.
GDPR violation: Article 5(1)(e) — storage limitation principle.
Fix: Define retention periods and implement automated deletion. Review and document retention policy annually.
Mistake 4: Missing Data Processing Agreement
Problem: No DPA exists between the venue operator (controller) and the WiFi platform (processor).
GDPR violation: Article 28 — processing by a processor must be governed by a contract.
Fix: Execute the platform's standard DPA. MyWiFi provides this on request for all plans.
Mistake 5: No process for data subject requests
Problem: When a guest emails requesting their data or deletion, nobody knows what to do.
GDPR violation: Articles 12–22 — data subject rights.
Fix: Document a response process, assign responsibility, and test it. Practice with a mock request annually.
MyWiFi GDPR-mode
MyWiFi Networks includes a GDPR-mode toggle that automatically configures compliant settings:
- •Consent checkbox defaults to unchecked
- •Separate WiFi and marketing consent flows
- •Consent records stored with timestamp, IP address, and text version
- •Automated data retention enforcement
- •Guest data deletion function
- •Privacy notice link requirement on portal
- •Consent withdrawal via unsubscribe in every message
- •DPA available for execution
GDPR-mode does not replace legal review — it provides technical implementation of common GDPR requirements. Resellers should consult local legal counsel for jurisdiction-specific guidance. View compliant platform plans to see which tier includes GDPR-mode and automated retention enforcement.
The ePrivacy Regulation: What is coming
The EU ePrivacy Regulation (ePR) has been in development since 2017 and is expected to finalize in 2026–2027. It will replace the current ePrivacy Directive (2002/58/EC) and specifically address:
- •WiFi tracking: The ePR draft explicitly addresses WiFi and Bluetooth tracking, potentially requiring consent for probe request processing (even anonymized)
- •Cookie-like storage: Regulations on device-side storage that may affect captive portal cookies and "Welcome Back" features
- •Metadata processing: Stricter rules on processing communications metadata, which may affect RADIUS accounting data
Resellers should monitor the ePR timeline and prepare for potential changes to WiFi analytics practices, particularly around presence analytics that rely on probe request detection.
FAQ
Does GDPR apply to my WiFi deployment if the venue is outside the EU? GDPR applies if you process personal data of individuals in the EU, regardless of where the venue is located. A hotel in the US serving European guests must comply with GDPR for those guests' data.
Is a MAC address personal data under GDPR? A MAC address alone is not always personal data. A MAC address combined with timestamps, location, or other data that can identify an individual is personal data under GDPR. For WiFi marketing purposes, treat MAC addresses as personal data — the combination with session data almost always makes them identifiable.
Can I use legitimate interest for email marketing? No. Direct marketing to individuals in the EU requires consent under GDPR Article 6(1)(a). Legitimate interest is not a valid basis for direct marketing emails. Legitimate interest may apply to anonymized analytics and B2B marketing in some jurisdictions, but not to individual consumer marketing.
What happens if a guest withdraws consent? Stop all marketing communications immediately. Retain the consent withdrawal record. The guest's WiFi access is not affected — only the marketing consent is withdrawn. You may retain anonymized analytical data.
Do I need a Data Protection Officer (DPO)? If the core activity of the venue involves regular and systematic monitoring of individuals on a large scale (e.g., a shopping mall with persistent WiFi tracking), a DPO may be required under Article 37. Consult local guidance — most single-venue restaurants and retail stores do not require a DPO.
How does GDPR interact with CCPA and CASL? GDPR (EU), CCPA (California), and CASL (Canada) have overlapping but distinct requirements. A multi-jurisdiction approach requires understanding each regulation and implementing the most restrictive requirement as the baseline. See our consent management guide for a multi-jurisdiction framework.