How to Protect Customer Data Collected via WiFi
This guide provides IT managers, network architects, and venue operations directors with a definitive technical reference for protecting customer data collected through guest WiFi deployments. It covers the full security stack — from WPA3 encryption and IEEE 802.1X access control through to GDPR-compliant consent flows, vendor due diligence, and breach notification obligations. Organisations operating in hospitality, retail, events, and public-sector environments will find actionable deployment guidance, real-world case studies, and measurable risk mitigation frameworks to implement this quarter.
🎧 Listen to this Guide
View Transcript
Executive Summary
Every guest WiFi connection is a data transaction. When a visitor authenticates at your captive portal — whether in a hotel lobby, a retail flagship, or a conference centre — they are exchanging personal data for network access. That exchange creates legal obligations, technical responsibilities, and reputational risk that must be managed with the same rigour applied to any enterprise data asset.
The threat landscape is not abstract. Misconfigured access points, unencrypted data in transit, and inadequate vendor contracts have resulted in multi-million-pound GDPR fines and class-action litigation. The UK Information Commissioner's Office issued £42.5 million in fines in 2023 alone, with data-handling failures at the root of the majority of cases.
This guide addresses how to protect customer data across the full guest WiFi lifecycle: from the moment a device probes your network through to long-term data retention and eventual deletion. It maps technical controls to compliance obligations, provides vendor-neutral architecture recommendations, and shows how platforms like Purple's Guest WiFi solution embed security and consent management directly into the guest experience. Whether you are conducting a security audit, planning a new deployment, or responding to a board-level risk review, this reference gives you the framework to act.
Technical Deep-Dive
The Data Surface: What Guest WiFi Actually Collects
Before designing controls, you need to understand what data is in play. A typical Guest WiFi deployment captures several categories of information, each carrying different risk profiles and regulatory implications.
| Data Category | Examples | Regulatory Classification |
|---|---|---|
| Identity Data | Email address, name, phone number | Personal Data (GDPR Art. 4) |
| Device Identifiers | MAC address, device type, OS version | Personal Data (post-Breyer ruling) |
| Behavioural Data | Dwell time, visit frequency, zone presence | Personal Data when linked to identity |
| Network Metadata | Connection timestamps, bandwidth usage, AP association | Potentially personal when aggregated |
| Consent Records | Timestamp, version of T&Cs accepted, marketing opt-in | Mandatory retention for compliance |
MAC address randomisation, now default on iOS 14+ and Android 10+, has changed the tracking landscape. Persistent identity now depends on authenticated sessions — email logins, social authentication, or loyalty programme integration — rather than passive device fingerprinting. This reinforces the importance of a well-designed captive portal that incentivises login.
Layer 1: Encryption Architecture
WPA3 (Wi-Fi Protected Access 3) is the non-negotiable baseline for any new deployment. Ratified by the Wi-Fi Alliance in 2018 and now mandatory for Wi-Fi 6 (802.11ax) certification, WPA3 addresses the fundamental weaknesses of WPA2-Personal: it replaces the four-way handshake with Simultaneous Authentication of Equals (SAE), eliminating offline dictionary attacks against captured handshakes. WPA3-Enterprise adds 192-bit minimum security mode, aligning with CNSA Suite requirements for high-security environments.
For venues that cannot immediately replace legacy hardware, WPA2 with AES-CCMP (not TKIP) is the minimum acceptable configuration. TKIP was deprecated in 802.11-2012 and must be disabled.
Data in transit beyond the access point must be protected by TLS 1.3. This applies to all API calls between the captive portal and the analytics backend, all data synchronisation between on-premises controllers and cloud platforms, and all administrative interfaces. TLS 1.2 is acceptable as a fallback where 1.3 is unsupported, but TLS 1.0 and 1.1 must be disabled — a requirement enforced by PCI DSS 4.0 since March 2024.
Data at rest — whether in a cloud analytics platform or an on-premises database — must use AES-256 encryption. This applies to the full data store, not just sensitive fields. Column-level encryption for high-sensitivity fields (email, phone) provides an additional layer of protection against SQL injection and insider threats.
Layer 2: Access Control and Authentication
IEEE 802.1X is the port-based network access control standard that underpins enterprise WiFi authentication. In a guest WiFi context, 802.1X is typically deployed in conjunction with a RADIUS server (Remote Authentication Dial-In User Service) to authenticate users before granting network access. The EAP (Extensible Authentication Protocol) framework within 802.1X supports multiple authentication methods: EAP-TLS (certificate-based, highest security), EAP-TTLS, and PEAP are the most common in enterprise deployments.
For guest networks where certificate distribution is impractical, the captive portal model remains standard. However, the captive portal must be treated as a security boundary, not merely a marketing touchpoint. Key requirements include HTTPS enforcement on the splash page (HTTP Strict Transport Security headers), CSRF protection on form submissions, rate limiting on authentication attempts, and session token expiry aligned with the guest's network session.
Role-Based Access Control (RBAC) must govern administrative access to the WiFi management platform. Principle of least privilege applies: venue staff should not have access to raw data exports; only designated data controllers should be able to initiate bulk data operations. All administrative actions must be logged with immutable audit trails.
Layer 3: Network Segmentation
Guest traffic must be isolated from internal networks using VLANs (Virtual Local Area Networks). This is a fundamental control that limits lateral movement in the event of a compromise. A well-designed segmentation architecture for a multi-use venue typically implements four VLANs at a minimum:
- VLAN 10 — Guest WiFi: Internet access only, no internal routing, DNS filtering enabled
- VLAN 20 — Corporate/Staff: Internal systems access, full security stack
- VLAN 30 — IoT/OT: Building management, CCTV, access control — isolated from both guest and corporate
- VLAN 40 — Management: Network infrastructure management, strictly access-controlled
Firewall rules must explicitly deny any routing between VLAN 10 and VLANs 20, 30, and 40. Egress filtering on the guest VLAN should block RFC 1918 address ranges to prevent guest devices from probing internal subnets. DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) on the guest VLAN prevents DNS-based data exfiltration and provides content filtering capabilities.
Layer 4: Consent and Data Governance
The captive portal is where technical architecture meets legal obligation. Under GDPR Article 7, consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes are prohibited. Bundling WiFi access with marketing consent is a grey area that the ICO has scrutinised — the safer position is to separate the two, offering WiFi access as the primary service and marketing communications as an optional, clearly distinct opt-in.
Purple's WiFi Analytics platform provides a consent management layer that records the precise timestamp, IP address, and version of the terms and conditions accepted by each user. This consent record is itself a data asset that must be retained for the duration of any potential legal challenge — typically six years under UK limitation periods.
Data minimisation (GDPR Article 5(1)(c)) requires that you collect only the data necessary for the stated purpose. If your stated purpose is network access management, you do not need a date of birth. If your stated purpose includes personalised marketing, you need explicit consent for that specific purpose, and the data collected must be proportionate to it. Refer to the How to Collect First-Party Data Through WiFi guide for a detailed breakdown of lawful collection frameworks.
Implementation Guide
Phase 1: Infrastructure Assessment (Weeks 1–2)
Begin with a full audit of your existing access point estate. Document the firmware version, WPA support level, and VLAN capability of every device. Identify any access points running WPA2-TKIP or operating without VLAN support — these are immediate remediation priorities. Simultaneously, review your network topology to confirm that guest and corporate traffic is physically or logically separated at the switching layer, not merely at the controller level.
Phase 2: Encryption Uplift (Weeks 2–4)
Deploy WPA3-Personal (SAE) on all guest SSIDs where hardware supports it. For mixed environments, enable WPA3 Transition Mode to maintain backward compatibility with WPA2 clients during the migration window. Update TLS configurations on all web-facing services to enforce TLS 1.3 as preferred, with TLS 1.2 as fallback. Disable TLS 1.0, 1.1, and all RC4 cipher suites. Validate configurations using tools such as SSL Labs or testssl.sh.
Phase 3: Access Control Deployment (Weeks 3–6)
Deploy or validate your RADIUS infrastructure. For cloud-managed networks, most enterprise controllers (Cisco Meraki, Aruba Central, Juniper Mist) provide built-in RADIUS proxy services. Configure 802.1X on staff and management SSIDs. For the guest SSID, configure the captive portal with HTTPS enforcement, session timeouts, and rate limiting. Integrate the captive portal with your analytics platform — Purple's Guest WiFi platform provides pre-built integrations with major controller vendors, eliminating custom development overhead.
Phase 4: VLAN Segmentation Validation (Weeks 4–6)
Validate VLAN isolation using penetration testing tools. From a guest VLAN device, confirm that you cannot reach any RFC 1918 address outside the guest subnet. Validate that DNS queries resolve correctly and that DoH or DoT is enforced. Test firewall rules by attempting to initiate connections from VLAN 10 to VLAN 20 — all such attempts should be logged and blocked.
Phase 5: Consent Flow and Data Governance (Weeks 5–8)
Review your captive portal consent flow against the ICO's consent guidance. Ensure that the privacy notice is accessible, plain-language, and version-controlled. Implement data retention policies in your analytics platform — Purple's platform supports configurable retention periods with automated anonymisation at expiry. Appoint or confirm your Data Protection Officer if your organisation meets the GDPR threshold, and register your processing activities in your Record of Processing Activities (ROPA).
Phase 6: Incident Response Planning (Weeks 7–10)
Document your breach response procedure. Assign roles: who detects, who contains, who notifies. Test the procedure with a tabletop exercise. Ensure your DPO has direct access to the analytics platform's audit logs and can export a full data subject access report within the 30-day GDPR deadline.
Best Practices
Encryption Standards: Deploy WPA3-SAE on all guest SSIDs. Enforce TLS 1.3 for all data in transit. Use AES-256 for all data at rest. These are not aspirational targets — they are the baseline expected by regulators and auditors in 2025.
Zero-Trust Posture on Guest Networks: Treat every guest device as untrusted, regardless of authentication status. Apply DNS filtering, bandwidth throttling, and egress controls as standard. Do not grant guest devices any implicit trust based on network location.
Vendor Due Diligence: Any third-party platform processing guest data on your behalf is a Data Processor under GDPR. You must have a Data Processing Agreement (DPA) in place. Verify ISO 27001 certification, conduct annual security questionnaires, and review sub-processor lists. Purple maintains ISO 27001 certification and provides a standard DPA as part of its enterprise contract.
Data Minimisation and Retention: Collect only what you need. Set automated retention limits — 90 days for raw session logs, 24 months for aggregated analytics, indefinite for consent records. Anonymise rather than delete where analytics value is retained.
Regular Penetration Testing: Commission annual penetration tests of your guest WiFi environment from a CREST-accredited provider. Include VLAN breakout testing, captive portal bypass attempts, and API security testing of your analytics platform integrations.
Staff Training: The most sophisticated technical controls can be undermined by a staff member plugging an unmanaged device into a corporate switch port. Annual security awareness training, with specific modules on guest network management, is a PCI DSS requirement and a GDPR best practice.
Worked Examples
Case Study 1: 450-Room Hotel Group — GDPR Compliance Overhaul
A UK hotel group operating 12 properties identified significant gaps during a pre-ICO audit: guest WiFi was running WPA2-TKIP, the captive portal had no version-controlled consent records, and guest and POS VLANs were on the same Layer 2 segment at three properties. The remediation programme, completed over 14 weeks, included access point firmware upgrades to enable WPA3 Transition Mode, deployment of Purple's Guest WiFi platform to replace a legacy captive portal solution, and a full VLAN re-architecture at all 12 properties. Post-deployment, the group achieved a 94% consent capture rate (versus 61% previously), reduced their data breach risk score by 67% in their cyber insurance assessment, and passed the ICO audit without remediation requirements. The Hospitality sector's specific challenge — high guest turnover, diverse device types, and POS integration requirements — makes this a representative deployment model.
Case Study 2: National Retail Chain — PCI DSS 4.0 Alignment
A 200-store retail chain faced PCI DSS 4.0 compliance requirements that mandated TLS 1.2 minimum on all cardholder data environment (CDE) adjacent networks. Their guest WiFi, while technically separate from the CDE, shared physical infrastructure with POS systems at 40 stores. The remediation involved deploying dedicated guest WiFi hardware at the 40 affected stores, implementing strict VLAN isolation with firewall ACLs validated by a QSA, and migrating the captive portal to Purple's platform with PCI DSS-aligned data handling. The Retail deployment reduced their PCI DSS scope at those 40 locations and eliminated a finding that had appeared in three consecutive annual QSA reports. The project delivered a measurable ROI: cyber insurance premium reduction of £180,000 per annum against a project cost of £240,000, achieving payback in 16 months.
Troubleshooting and Risk Mitigation
VLAN Leakage: The most common failure mode in guest WiFi deployments is VLAN misconfiguration at the switching layer. Symptoms include guest devices being able to ping internal hosts or access internal web interfaces. Diagnosis: run a network scan from a guest VLAN device and check for RFC 1918 responses outside the guest subnet. Remediation: review trunk port configurations on all switches in the path from access point to firewall, and validate ACLs at the firewall.
Captive Portal Bypass: Sophisticated users can bypass captive portals using DNS tunnelling or by connecting to a known open DNS resolver before the portal redirect fires. Mitigate by blocking all outbound DNS (port 53 UDP/TCP) from the guest VLAN except to your designated resolver, and by implementing DNS-based captive portal detection (RFC 8910).
MAC Randomisation and Analytics Gaps: iOS and Android devices now randomise MAC addresses per SSID, breaking session continuity for unauthenticated users. The correct response is not to attempt MAC de-randomisation (which is technically difficult and legally questionable) but to design your captive portal to incentivise authenticated login. Authenticated sessions provide persistent identity that survives MAC changes.
Consent Record Loss: If your captive portal platform does not maintain immutable consent records, you have no defence against a subject access request or regulatory investigation. Ensure your platform exports consent records in a format that can be retained independently of the platform itself — Purple's platform provides JSON and CSV export of all consent records with cryptographic timestamps.
Vendor Breach Notification: Your Data Processing Agreement must specify the vendor's obligation to notify you of a breach within 24 hours of discovery — giving you sufficient time to meet your own 72-hour ICO notification deadline. If your current DPA does not contain this clause, it requires immediate renegotiation.
ROI and Business Impact
The business case for investing in guest WiFi data security operates on two axes: risk mitigation and revenue enablement.
On the risk side, GDPR fines can reach 4% of global annual turnover or £17.5 million, whichever is higher. For a mid-market hotel group with £50 million turnover, that ceiling is £2 million. Cyber insurance premiums for organisations with demonstrable security controls — WPA3, 802.1X, ISO 27001-certified vendors — are typically 20–35% lower than for those without. The average cost of a data breach in the UK in 2024 was £3.4 million when including investigation, remediation, regulatory response, and reputational damage.
On the revenue side, a secure and well-designed guest WiFi platform is a first-party data engine. Venues using Purple's WiFi Analytics platform report average consent capture rates of 85–92%, generating opted-in marketing databases that drive measurable revenue through targeted campaigns. A 500-room hotel capturing 300 new opted-in contacts per day builds a database of 100,000 verified contacts in under a year — a marketing asset with a conservative lifetime value of £500,000 to £1 million.
The security investment is not a cost centre. It is the foundation that makes the data asset legitimate, defensible, and commercially exploitable. Organisations in Healthcare , Transport , and public-sector environments face additional regulatory scrutiny — the investment case is even stronger where sector-specific regulations (NIS2, DSPT, CAF) layer on top of GDPR obligations.
For further context on how guest WiFi integrates with broader IoT and location intelligence architectures, see the Internet of Things Architecture: A Complete Guide and the Indoor Positioning System: UWB, BLE, and WiFi Guide .
Key Terms & Definitions
WPA3 (Wi-Fi Protected Access 3)
The current Wi-Fi security standard, ratified in 2018, that replaces WPA2. WPA3-Personal uses Simultaneous Authentication of Equals (SAE) to eliminate offline dictionary attacks. WPA3-Enterprise adds 192-bit minimum security mode. Mandatory for Wi-Fi 6 (802.11ax) certification.
IT teams encounter this when specifying access point procurement or auditing existing deployments. Any access point that cannot support WPA3 should be flagged for replacement in the next hardware refresh cycle.
IEEE 802.1X
A port-based network access control standard that requires devices to authenticate before being granted network access. Works in conjunction with a RADIUS server and the EAP (Extensible Authentication Protocol) framework. Prevents unauthorised devices from connecting to the network.
Relevant for staff and management SSIDs where certificate-based or credential-based authentication is required. On guest networks, typically replaced by captive portal authentication, but 802.1X principles inform the overall access control architecture.
RADIUS (Remote Authentication Dial-In User Service)
A networking protocol that provides centralised authentication, authorisation, and accounting (AAA) for network access. In WiFi deployments, the RADIUS server validates credentials presented via 802.1X and returns access policies to the network controller.
IT teams deploy RADIUS servers (Microsoft NPS, FreeRADIUS, Cisco ISE) as the backend for 802.1X authentication. Cloud-managed network platforms often include hosted RADIUS services, reducing on-premises infrastructure requirements.
VLAN (Virtual Local Area Network)
A logical network segment created within a physical switching infrastructure. VLANs allow multiple isolated networks to share the same physical hardware while preventing traffic from crossing segment boundaries without explicit routing and firewall rules.
The primary mechanism for separating guest WiFi traffic from corporate, POS, and IoT networks. VLAN misconfiguration is the most common cause of guest-to-corporate network leakage in venue deployments.
TLS 1.3 (Transport Layer Security 1.3)
The current version of the cryptographic protocol that secures data in transit over networks. TLS 1.3 removes support for weak cipher suites, reduces handshake latency, and provides forward secrecy by default. TLS 1.0 and 1.1 are deprecated; TLS 1.2 is acceptable but TLS 1.3 is preferred.
Relevant for all web-facing services including captive portals, analytics dashboards, and API endpoints. PCI DSS 4.0 (effective March 2024) requires TLS 1.2 minimum on all systems in or adjacent to the cardholder data environment.
AES-256 (Advanced Encryption Standard, 256-bit)
A symmetric encryption algorithm with a 256-bit key length, considered computationally infeasible to brute-force with current and near-future technology. The standard for encrypting data at rest in enterprise systems.
IT teams should verify that their WiFi analytics platform and any associated databases use AES-256 for data at rest. This is a standard requirement in ISO 27001 implementations and is specified in most enterprise security policies.
Captive Portal
A web page presented to users when they connect to a guest WiFi network, before full internet access is granted. Used to collect authentication credentials, display terms and conditions, gather consent for data processing, and redirect users to branded content.
The captive portal is both a security control and a compliance mechanism. It must enforce HTTPS, implement CSRF protection, version-control its terms and conditions, and record consent with timestamps. It is also the primary data collection touchpoint for guest WiFi analytics platforms.
Data Processing Agreement (DPA)
A legally binding contract required under GDPR Article 28 between a Data Controller (the venue operator) and a Data Processor (the WiFi platform vendor). It specifies the scope of processing, security obligations, breach notification timelines, sub-processor restrictions, and data deletion requirements.
Mandatory for any third-party vendor that processes personal data on your behalf. Absence of a DPA is itself a GDPR violation. IT teams should ensure a signed DPA is in place before any guest data flows to a third-party platform.
SAE (Simultaneous Authentication of Equals)
The handshake protocol used in WPA3-Personal, replacing the Pre-Shared Key (PSK) handshake of WPA2. SAE is resistant to offline dictionary attacks because it does not expose a capturable handshake that can be brute-forced after the fact.
IT teams should understand SAE as the core security improvement of WPA3 over WPA2. When evaluating access point hardware, SAE support is the key capability to verify for WPA3 compliance.
GDPR Article 7 Consent
The legal standard for valid consent under the General Data Protection Regulation. Consent must be freely given, specific, informed, and unambiguous. It must be as easy to withdraw as to give. Pre-ticked boxes and bundled consent are prohibited.
Directly applicable to guest WiFi captive portals where personal data is collected. The ICO has issued guidance specifically on WiFi consent, and venues must ensure their captive portal design meets the Article 7 standard.
Case Studies
A 450-room hotel group operating 12 UK properties is preparing for an ICO audit. Their current guest WiFi runs WPA2-TKIP, the captive portal has no version-controlled consent records, and at three properties the guest and POS VLANs share the same Layer 2 segment. What is the remediation priority order and what outcomes should they target?
Priority 1 (immediate, Week 1): Disable TKIP on all access points and enforce WPA2-AES as the minimum. This eliminates the most critical encryption vulnerability without requiring hardware replacement. Priority 2 (Week 1–2): Physically or logically separate guest and POS VLANs at the three affected properties. This is a PCI DSS requirement and limits breach blast radius. Configure explicit deny ACLs at the firewall between VLAN segments. Priority 3 (Weeks 2–6): Deploy a compliant captive portal platform (such as Purple) that provides version-controlled consent records with cryptographic timestamps. Migrate all 12 properties to a unified consent management system. Priority 4 (Weeks 4–8): Upgrade access points that support WPA3 to WPA3 Transition Mode. Commission a penetration test to validate VLAN isolation. Target outcomes: 90%+ consent capture rate, zero VLAN leakage findings in pen test, full consent record audit trail available for ICO review.
A 200-store retail chain is preparing for PCI DSS 4.0 assessment. At 40 stores, guest WiFi shares physical switching infrastructure with POS systems. The QSA has flagged this as a scope expansion risk. What is the correct architectural response?
The correct response is network segmentation that removes guest WiFi from PCI DSS scope entirely. Deploy dedicated access points for guest WiFi at the 40 affected stores, connected to a separate switch or switch port group with no trunk connectivity to the POS VLAN. Configure firewall ACLs to explicitly deny any routing between the guest VLAN (e.g., 10.10.10.0/24) and the CDE VLAN (e.g., 10.20.20.0/24). Validate isolation with a network scan from a guest device — no CDE hosts should be reachable. Document the segmentation architecture in a network diagram and present it to the QSA as evidence of scope reduction. Additionally, migrate the captive portal to a PCI DSS-aligned platform that does not process cardholder data and maintains its own security certification.
A conference centre operator discovers that a third-party WiFi vendor they have been using for three years does not have a Data Processing Agreement in place and cannot demonstrate ISO 27001 certification. A data subject access request has just been received. What are the immediate obligations and remediation steps?
Immediate obligations: (1) Respond to the DSAR within 30 days — this is a legal obligation regardless of the vendor situation. Request a full data export from the vendor covering all data held on the requesting individual. (2) Assess whether the absence of a DPA constitutes a reportable breach — if personal data has been processed without a lawful basis or adequate safeguards, this may require ICO notification within 72 hours. (3) Engage legal counsel to assess liability exposure. Remediation steps: (1) Issue a DPA to the vendor immediately and require execution within 5 business days. (2) Request the vendor's security certifications and conduct an emergency security questionnaire. (3) If the vendor cannot demonstrate adequate security measures, initiate a procurement process for a compliant replacement platform. (4) Document all remediation steps for the ICO record. (5) Appoint a DPO if not already in place and update the ROPA to reflect the corrected processing basis.
Scenario Analysis
Q1. Your organisation operates a 300-seat conference centre. A security consultant has flagged that your guest WiFi captive portal is served over HTTP, not HTTPS. The venue manager argues that 'it's just a login page, not a payment page.' How do you respond, and what is the remediation?
💡 Hint:Consider what data is transmitted at the captive portal and what regulatory obligations apply, independent of whether payment data is involved.
Show Recommended Approach
The venue manager's argument conflates PCI DSS scope (which is payment-specific) with GDPR obligations (which apply to all personal data). A captive portal served over HTTP transmits credentials, email addresses, and consent records in plaintext — any attacker on the same network segment can intercept this data via a passive sniff. This is a GDPR data security failure under Article 32, which requires 'appropriate technical measures' to protect personal data. Remediation: (1) Obtain and install a TLS certificate on the captive portal server — Let's Encrypt provides free certificates for public-facing services. (2) Configure HTTPS redirect for all HTTP requests to the portal. (3) Implement HSTS (HTTP Strict Transport Security) headers to prevent downgrade attacks. (4) Validate the configuration using SSL Labs. This is a low-cost, high-impact remediation that should be completed within 48 hours.
Q2. You are the IT Director of a retail chain preparing for a PCI DSS 4.0 assessment. Your QSA has indicated that your guest WiFi network, which shares switching infrastructure with your POS systems at 60 stores, will expand your PCI DSS scope unless you can demonstrate adequate segmentation. What evidence do you need to produce, and what is the minimum viable architecture?
💡 Hint:PCI DSS scope is determined by network connectivity, not just logical configuration. The QSA needs to verify that a compromise of the guest network cannot reach the CDE.
Show Recommended Approach
The minimum viable architecture requires: (1) Dedicated VLANs for guest WiFi (e.g., VLAN 10) and POS/CDE (e.g., VLAN 20) with no trunk connectivity between them except through a firewall. (2) Firewall ACLs that explicitly deny all traffic from VLAN 10 to VLAN 20, with logging enabled. (3) Validation via network scan from a guest VLAN device — no CDE hosts should be reachable. Evidence to produce for the QSA: (a) Network topology diagram showing VLAN assignments and firewall placement, (b) Firewall ruleset showing explicit deny rules, (c) Network scan results from the guest VLAN confirming no CDE hosts are reachable, (d) Switch configuration showing VLAN assignments and trunk port configurations. If the shared switching infrastructure cannot support adequate VLAN isolation (e.g., unmanaged switches), physical separation with dedicated guest WiFi access points connected to a separate switch is required.
Q3. A data subject contacts your venue claiming they never consented to receive marketing emails, despite being on your guest WiFi marketing list. Your current captive portal platform cannot produce a consent record for this individual. What are your obligations, and how do you prevent this situation in future deployments?
💡 Hint:Consider both the immediate DSAR obligation and the systemic platform capability gap this reveals.
Show Recommended Approach
Immediate obligations: (1) Acknowledge the DSAR within 5 working days and respond within 30 calendar days. (2) Cease marketing communications to this individual immediately — the burden of proof for consent lies with the controller, not the data subject. If you cannot produce a consent record, you must treat the processing as unlawful. (3) Assess whether the inability to produce consent records for any individual constitutes a systemic failure requiring ICO notification. (4) Remove the individual from all marketing lists and document the action. Systemic remediation: (1) Replace or upgrade the captive portal platform with one that provides immutable, timestamped, version-controlled consent records — Purple's platform provides this as a standard capability. (2) Conduct a retrospective audit of your marketing database to identify any contacts for whom consent records cannot be produced, and remove them. (3) Update your ROPA to reflect the corrected consent basis. (4) Implement a consent record export test as part of your quarterly compliance review. The inability to produce consent records is one of the most common ICO enforcement triggers and is entirely preventable with the right platform.
