GDPR and WiFi: ব্যবসার জন্য একটি সম্মতি নির্দেশিকা

GDPR AND WIFI: A COMPLIANCE GUIDE FOR BUSINESSES A Purple Intelligence Briefing — approximately 10 minutes [INTRODUCTION & CONTEXT — 1 minute] Welcome to the Purple Intelligence Briefing. I'm your host, and today we're cutting straight to the point on one of the most misunderstood compliance challenges facing venue operators and IT teams right now: GDPR and WiFi. If you're running guest WiFi across a hotel estate, a retail chain, a stadium, or a public-sector building — you are collecting personal data. Full stop. And whether you realise it or not, that collection is subject to the General Data Protection Regulation. The ICO has been increasingly active in this space, and the consequences of getting it wrong range from enforcement notices all the way to fines of up to four percent of global annual turnover. But here's the thing — GDPR compliance for WiFi is not as complicated as the legal teams sometimes make it sound. It comes down to four core questions: What data are you collecting? On what legal basis? How long are you keeping it? And who is responsible? Answer those four questions correctly, and you're most of the way there. Let's get into it. [TECHNICAL DEEP-DIVE — 5 minutes] So, let's start with what data a typical guest WiFi deployment actually collects. When a guest connects to your network through a captive portal — that's the splash page they see before they get internet access — you're potentially capturing a MAC address, an IP address, a connection timestamp, session duration, and if you've built in a registration flow, an email address, a name, and marketing preferences. Now, MAC addresses and IP addresses are classified as personal data under GDPR because they can be used to identify an individual. That surprises a lot of network architects. They think of those as technical identifiers, not personal data. But the regulation is clear: if it can be used, directly or indirectly, to identify a natural person, it's personal data. So your network logs are in scope from the moment a device connects. The next question is lawful basis. Under Article 6 of the GDPR, you need one of six lawful bases to process personal data. For guest WiFi, the two that matter most are consent and legitimate interests. Consent is the cleaner option when you're collecting email addresses for marketing purposes. Under GDPR, consent must be freely given, specific, informed, and unambiguous. That means no pre-ticked boxes. No bundling marketing consent into the terms and conditions. The guest must actively opt in, and you must be able to demonstrate that they did — with a timestamp and a record of what they consented to at that point in time. Legitimate interests is the basis most operators use for the underlying network connection data — things like MAC addresses and session logs. The argument is that operating a secure, functional network is a legitimate interest of the business, and that interest is not overridden by the individual's privacy rights. But — and this is important — you still need to conduct and document a Legitimate Interests Assessment, or LIA. You can't just assert legitimate interests and move on. The ICO expects to see the three-part test: purpose, necessity, and balancing. Now let's talk about splash page design, because this is where most organisations trip up. The splash page is your primary consent interface, and it needs to do several things simultaneously. It needs to identify who is collecting the data — that's your organisation's name. It needs to explain what data is being collected and why. It needs to present any marketing opt-in as a separate, unticked checkbox. And it needs to link to a full privacy notice that covers data subject rights. What it must not do is make network access conditional on marketing consent. If you gate the WiFi behind an email sign-up where the only way to connect is to agree to receive marketing emails, that consent is not freely given under GDPR. The ICO has been explicit on this. You can offer an incentive for providing an email address — a loyalty point, a discount voucher — but the baseline network access must be available regardless. Moving on to data retention. Article 5(1)(e) of the GDPR sets out the storage limitation principle: personal data must not be kept for longer than is necessary for the purpose for which it was collected. For guest WiFi, that means you need a documented retention schedule. Network security logs — things like MAC addresses and session timestamps — are typically retained for 90 days for security and fraud investigation purposes. That's a defensible position. Email addresses collected for marketing can be retained for longer, but you need to define that period, communicate it in your privacy notice, and enforce it technically — not just as a policy on paper. This is where the technology stack matters. A platform like Purple's guest WiFi solution automates retention enforcement. You configure a retention window, and the system purges records automatically. That's the difference between a compliance policy and a compliance programme. The policy says what you'll do. The programme proves you did it. Let's talk about Data Protection Agreements, or DPAs. If you're using a third-party platform to manage your guest WiFi — which most organisations are — that platform is acting as a data processor on your behalf. Under Article 28 of the GDPR, you must have a written Data Processing Agreement in place with that processor. The DPA must specify what data is being processed, for what purpose, under what instructions, and what security measures the processor has in place. If you're using a cloud-based WiFi analytics platform and you don't have a signed DPA, you are non-compliant. It's that simple. For organisations operating across multiple EU member states or serving EU residents from a UK base post-Brexit, you also need to consider the UK GDPR — which is essentially the EU GDPR as retained in UK law — and whether any international data transfers are involved. If your WiFi platform stores data on servers outside the UK or EEA, you need an appropriate transfer mechanism: either an adequacy decision, standard contractual clauses, or binding corporate rules. [IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — 2 minutes] Right, let's get practical. Here are the four implementation steps I'd recommend to any IT team or venue operator starting this process. First: conduct a data mapping exercise. Before you touch your splash page or your privacy notice, map out every piece of data your WiFi deployment collects, where it goes, who has access to it, and how long it's kept. This is your Record of Processing Activities under Article 30, and it's the foundation of everything else. Second: audit your splash page against the consent requirements. Check for pre-ticked boxes. Check that marketing consent is separate from terms acceptance. Check that your privacy notice link is visible and functional. If you're using a platform like Purple, the consent management tools are built in — but you still need to configure them correctly and review the copy. Third: get your DPAs in place. Contact every third-party vendor that touches your WiFi data — your platform provider, your analytics tool, your CRM — and confirm that a signed DPA is in place. If it isn't, get one before you go any further. Fourth: implement technical retention controls. Don't rely on manual processes to delete old data. Configure automated purging in your platform, and document the configuration as evidence of compliance. The most common pitfall I see is organisations treating GDPR as a one-time project rather than an ongoing programme. You do the audit, you update the splash page, you file the DPA, and then two years later the platform has been upgraded, the splash page copy has been changed by the marketing team, and nobody has reviewed the retention settings. GDPR compliance requires a periodic review cycle — at minimum annually, and whenever there's a significant change to your data processing activities. [RAPID-FIRE Q&A — 1 minute] A few questions I get asked regularly. "Do we need a DPO?" — If you're a public authority, or if your core activities involve large-scale systematic monitoring of individuals — which a large guest WiFi deployment could qualify as — then yes, you need a designated Data Protection Officer. For smaller deployments, it's best practice even if not strictly mandatory. "Can we use MAC addresses for footfall analytics?" — Yes, but only if you're using anonymised or aggregated data. If you're tracking individual MAC addresses across sessions to build movement profiles, that's personal data processing and you need a lawful basis and a privacy notice disclosure. "What about children?" — If your venue is likely to be accessed by children under 13, you need to consider the ICO's Children's Code. That means no behavioural profiling of children and age-appropriate privacy notices. [SUMMARY AND NEXT STEPS — 1 minute] To wrap up: GDPR and WiFi compliance is entirely achievable. The regulation is not designed to prevent you from running a guest WiFi service or collecting data to improve your operations. It's designed to ensure that when you do collect data, you do it transparently, on a valid legal basis, with appropriate security, and with respect for individuals' rights. The four things to take away from this briefing: establish your lawful basis and document it; design your splash page for genuine consent; get your DPAs signed; and enforce retention technically, not just on paper. If you want to go deeper on any of these areas, Purple has a full set of implementation guides on first-party data collection through WiFi, and the platform itself is built to support GDPR-compliant deployments out of the box. Thanks for listening. Until next time.