ভারত DPDP আইন: ভারতীয় স্থানগুলির জন্য অতিথি WiFi সম্মতি

India DPDP Act: Guest WiFi Compliance for Indian Venues A Purple Technical Briefing — Approximately 10 Minutes [INTRODUCTION & CONTEXT — 1 minute] Welcome to the Purple Technical Briefing. I'm your host, and today we're diving into something that should be on every IT director's and compliance lead's radar right now: India's Digital Personal Data Protection Act — the DPDP Act — and what it means specifically for guest WiFi deployments across Indian venues. Whether you're running a hotel chain in Mumbai, a retail estate in Bengaluru, a stadium in Hyderabad, or the Indian arm of a multinational — if you're operating guest WiFi and capturing sign-up data through a captive portal, this legislation directly affects you. The rules are live, enforcement is ramping up, and the penalties are substantial. We're talking up to two hundred and fifty crore rupees for security failures alone. So let's get into it. Over the next ten minutes, I'll walk you through the core obligations, show you how this differs from GDPR in practice, give you a practical retention framework, and flag the three most common mistakes venues are making right now. [TECHNICAL DEEP-DIVE — 5 minutes] Let's start with the fundamentals. The Digital Personal Data Protection Act was enacted in August 2023, with the implementing rules finalised in late 2025. Compliance timelines are running on a phased twelve to eighteen month basis from when the rules came into force — so if you haven't started your compliance programme, you're already behind. The first thing to understand is the terminology. Under the DPDP Act, your venue is the Data Fiduciary — you decide why and how personal data is processed. Your WiFi platform provider — whether that's Purple or any other vendor — is the Data Processor. And your guest is the Data Principal. This distinction matters enormously because under DPDP, unlike GDPR, all compliance liability sits with the Data Fiduciary. Your platform provider's DPA doesn't transfer your risk. You own it. Now, consent. This is where most venues get tripped up. Section 6 of the Act requires consent to be free, specific, informed, unconditional, and unambiguous with a clear affirmative action. That word "unconditional" is unique to DPDP — it's not in GDPR — and it has real teeth. It means you cannot make marketing consent a condition of receiving WiFi access. Full stop. What does that look like in practice on a captive portal? You need three things. First, a DPDP-compliant notice displayed before any data is collected — this must state what data you're collecting, why, how long you'll keep it, how the guest can withdraw consent, and how they can contact your Data Protection Officer or designated responsible person. Second, granular consent checkboxes: one for network access — which is the necessary processing — and separate, optional checkboxes for marketing communications and analytics or profiling. These must be unchecked by default. Third, you must record the consent — timestamp, IP address, consent version, and exactly what was agreed to — and you must be able to produce that record on request. One practical note on the captive portal mechanics: if you're deploying on Apple iOS devices, Android, or Windows machines, the Captive Network Assistant — or CNA — behaves differently on each platform. Apple's CNA opens a mini-browser that has limitations around cookies and redirects. You need to ensure your consent mechanism works within those constraints. Purple's guide on captive portal detection covers the technical implementation in detail — it's worth reading alongside this compliance briefing. Now let's talk about data retention, because this is where I see the most confusion. The DPDP Act's approach is purpose-driven. Under Section 8(7), you must erase personal data when either the Data Principal withdraws consent, or when the specified purpose is no longer being served — whichever comes first. Rule 8 then adds two important overlays. First, for certain high-volume platforms — e-commerce with over two crore users, social media, online gaming — the Third Schedule sets a three-year deemed cessation period. If there's been no interaction for three years, the purpose is deemed no longer served. For most venue operators — hotels, retail, stadiums — you won't fall into these specific Third Schedule categories, so you apply the general Section 8(8) principle: if the guest hasn't interacted with you or exercised their rights for a reasonable period, you should erase their data. Second, Rule 8(3) creates a minimum floor: you must retain processing logs and associated data for at least one year from the date of processing, regardless of purpose cessation. This is for audit and regulatory purposes. So for a practical venue retention policy, here's the framework I'd recommend: retain active guest WiFi profiles for the duration of the relationship plus one year. If a guest hasn't connected or engaged for twenty-four months, trigger a re-consent or erasure workflow. Maintain processing logs for a minimum of one year. For hotel guests, the stay creates a legitimate processing relationship — but post-stay marketing requires separate consent, and that consent has its own retention clock. Now, cross-border data transfers. This is actually simpler under DPDP than under GDPR. The Act uses a blacklist approach — transfers are permitted to all countries unless the Central Government specifically restricts a particular country or territory by notification. Contrast that with GDPR's whitelist approach, where you need an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules for every transfer to a non-adequate country. For multinational venues using cloud-based WiFi platforms with data centres outside India, you currently have more flexibility under DPDP — but watch this space, because the Government's notification powers mean the landscape can change. Let me also cover the rights your guests have under DPDP, because your IT and operations teams need to be able to respond to them. Data Principals have the right to access information about their processing, the right to correction and erasure, and the right to grievance redressal — with a mandatory ninety-day response window. What they don't have, unlike under GDPR, is the right to data portability, the right to object to automated decision-making, or the right to restriction of processing. That's a narrower rights framework, which simplifies your response obligations somewhat. Children's data is a separate, higher-risk category. Under DPDP, verifiable parental consent is required for processing data of anyone under eighteen. If your venue WiFi is in a family environment — a mall, a theme park, a family hotel — you need a mechanism to identify and handle minor users. This is a non-trivial technical and operational challenge that many venues haven't addressed. [IMPLEMENTATION RECOMMENDATIONS & PITFALLS — 2 minutes] Let me give you the three most common pitfalls I see, and how to avoid them. Pitfall one: bundled consent. This is the most frequent violation. Venues present a single "I agree to the terms and conditions" checkbox that covers both network access and marketing. Under DPDP Section 6, this is non-compliant. The fix is straightforward — separate your consent into distinct, purpose-specific checkboxes, and ensure the marketing one is optional and unchecked by default. Pitfall two: no consent audit trail. If the Data Protection Board asks you to demonstrate that a specific guest gave consent on a specific date for a specific purpose, can you produce that record? Most venues cannot. Your WiFi platform must store consent records with sufficient granularity — timestamp, session ID, IP address, consent version, and the specific purposes consented to. Purple's platform captures this natively, but if you're on a legacy system, this is a gap you need to close urgently. Pitfall three: no data processor agreement. Under Section 8(2), you must have a valid contract with any Data Processor you engage. If your WiFi platform provider doesn't have a current Data Processing Agreement that references DPDP obligations, you're exposed. This isn't just a legal formality — it's a prerequisite for the Data Fiduciary's compliance defence. On the implementation side, the key architectural decision is where consent data is stored and how it integrates with your CRM or marketing automation platform. You need a single source of truth for consent status that your marketing team cannot override. Consent withdrawal must propagate to all downstream systems within a reasonable timeframe — I'd recommend a maximum of seventy-two hours as your operational SLA. For venues with multiple properties — hotel chains, retail estates — you need to decide whether consent given at one property extends to others. Under DPDP's specificity requirement, the safest position is property-level consent unless your notice explicitly covers the group, and guests have consented to group-wide processing. [RAPID-FIRE Q&A — 1 minute] Let me run through a few questions I get regularly. "Can I use WiFi analytics — footfall counting, dwell time — without consent?" If the data is genuinely anonymised and cannot be linked back to an individual, it falls outside the DPDP Act's scope. But MAC address randomisation means device-level tracking is increasingly unreliable anyway. For identified analytics, you need consent. "Do I need a Data Protection Officer?" A full DPO is mandatory only for Significant Data Fiduciaries — a classification the Government will notify. For most venue operators, you need a designated responsible person whose contact details are published. That's a lower bar, but it still needs to be someone who can actually answer data protection questions. "What's the penalty exposure for a mid-size hotel chain?" A security failure that leads to a breach carries up to two hundred and fifty crore rupees. Failure to notify the Board of a breach is another two hundred crore. These are fixed caps, not percentages of turnover — which means they hit smaller organisations proportionally harder than GDPR's turnover-based penalties hit large multinationals. [SUMMARY & NEXT STEPS — 1 minute] To wrap up, here are your five immediate actions. One: audit your captive portal consent flow today. If it has a single checkbox or bundles marketing with access, it needs to be rebuilt. Two: implement a consent audit trail. Every consent event must be logged with timestamp, IP, purpose, and version. Three: establish a data retention policy. For most venues, a twenty-four month inactivity trigger for re-consent or erasure is a reasonable starting point, with a one-year minimum for processing logs. Four: review your Data Processing Agreements with your WiFi platform provider and any downstream marketing or analytics vendors. Five: designate a responsible person for data protection queries and publish their contact details on your captive portal and website. The DPDP Act is not as complex as GDPR in terms of the breadth of obligations, but it is equally serious in terms of enforcement intent. The Data Protection Board has real teeth, and the penalty structure is designed to be meaningful even for large organisations. For a deeper dive into captive portal architecture, Purple's technical guides cover the implementation specifics in detail. And if you're looking at how guest WiFi analytics integrates with your broader venue intelligence stack, the Purple WiFi Analytics platform is built with consent-first data capture at its core. Thanks for listening. Until next time.