India DPDP Act: Guest WiFi Compliance for Indian Venues

Lei DPDP da Índia: Conformidade de Guest WiFi para Estabelecimentos Indianos Um Briefing Técnico da Purple — Aproximadamente 10 Minutos [INTRODUÇÃO & CONTEXTO — 1 minuto] Bem-vindo ao Briefing Técnico da Purple. Sou o seu anfitrião e hoje vamos nos aprofundar em algo que deve estar no radar de todo diretor de TI e líder de conformidade agora: a Lei de Proteção de Dados Pessoais Digitais da Índia — a Lei DPDP — e o que ela significa especificamente para implantações de guest WiFi em estabelecimentos indianos. Seja você o administrador de uma rede de hotéis em Mumbai, uma rede de varejo em Bengaluru, um estádio em Hyderabad ou a filial indiana de uma multinacional — se você opera guest WiFi e captura dados de cadastro por meio de um Captive Portal, esta legislação afeta você diretamente. As regras estão em vigor, a fiscalização está aumentando e as penalidades são substanciais. Estamos falando de até duzentos e cinquenta crore de rúpias apenas para falhas de segurança. Então, vamos ao que interessa. Nos próximos dez minutos, vou guiar você pelas principais obrigações, mostrar como isso difere do GDPR na prática, apresentar uma estrutura prática de retenção e apontar os três erros mais comuns que os estabelecimentos estão cometendo agora. [APROFUNDAMENTO TÉCNICO — 5 minutos] Vamos começar com os fundamentos. A Lei de Proteção de Dados Pessoais Digitais foi promulgada em agosto de 2023, com as regras de implementação finalizadas no final de 2025. Os cronogramas de conformidade estão ocorrendo em uma base faseada de doze a dezoito meses a partir da entrada em vigor das regras — portanto, se você ainda não iniciou seu programa de conformidade, já está atrasado. A primeira coisa a entender é a terminologia. Sob a Lei DPDP, seu estabelecimento é o Fiduciário de Dados (Data Fiduciary) — você decide por que e como os dados pessoais são processados. Seu provedor de plataforma de WiFi — seja a Purple ou qualquer outro fornecedor — é o Processador de Dados (Data Processor). E seu convidado é o Titular dos Dados (Data Principal). Essa distinção importa enormemente porque, sob a DPDP, ao contrário do GDPR, toda a responsabilidade de conformidade recai sobre o Fiduciário de Dados. O DPA do seu provedor de plataforma não transfere o seu risco. Ele é seu. Agora, o consentimento. É aqui que a maioria dos estabelecimentos se confunde. A Seção 6 da Lei exige que o consentimento seja livre, específico, informado, incondicional e inequívoco, com uma ação afirmativa clara. Essa palavra "incondicional" é exclusiva da DPDP — não está no GDPR — e tem força real. Isso significa que você não pode tornar o consentimento de marketing uma condição para receber acesso ao WiFi. Ponto final.Como isso se parece na prática em um Captive Portal? Você precisa de três coisas. Primeiro, um aviso em conformidade com a DPDP exibido antes que qualquer dado seja coletado — este deve declarar quais dados você está coletando, por que, por quanto tempo os manterá, como o visitante pode retirar o consentimento e como ele pode entrar em contato com o seu Encarregado de Proteção de Dados ou pessoa responsável designada. Segundo, caixas de seleção de consentimento granulares: uma para acesso à rede — que é o processamento necessário — e caixas de seleção separadas e opcionais para comunicações de marketing e análises ou profiling. Estas devem estar desmarcadas por padrão. Terceiro, você deve registrar o consentimento — carimbo de data/hora, endereço IP, versão do consentimento e exatamente o que foi acordado — e você deve ser capaz de apresentar esse registro mediante solicitação. Uma nota prática sobre a mecânica do Captive Portal: se você estiver implantando em dispositivos Apple iOS, Android ou máquinas Windows, o Captive Network Assistant — ou CNA — se comporta de maneira diferente em cada plataforma. O CNA da Apple abre um mini-navegador que possui limitações em relação a cookies e redirecionamentos. Você precisa garantir que seu mecanismo de consentimento funcione dentro dessas restrições. O guia da Purple sobre detecção de Captive Portal aborda a implementação técnica em detalhes — vale a pena ler junto com este briefing de conformidade. Agora vamos falar sobre retenção de dados, porque é aqui que vejo a maior confusão. A abordagem da Lei DPDP é orientada por propósitos. De acordo com a Seção 8(7), você deve apagar os dados pessoais quando o Titular dos Dados retirar o consentimento ou quando a finalidade especificada não estiver mais sendo atendida — o que ocorrer primeiro. A Regra 8 adiciona duas sobreposições importantes. Primeiro, para certas plataformas de alto volume — e-commerce com mais de duas dezenas de milhões de usuários, mídias sociais, jogos online — o Terceiro Cronograma estabelece um período de cessação presumido de três anos. Se não houver interação por três anos, considera-se que a finalidade não está mais sendo atendida. Para a maioria dos operadores de locais — hotéis, varejo, estádios — você não se enquadrará nessas categorias específicas do Terceiro Cronograma, portanto, aplica o princípio geral da Seção 8(8): se o visitante não interagiu com você ou não exerceu seus direitos por um período razoável, você deve apagar seus dados. Segundo, a Regra 8(3) cria um limite mínimo: você deve reter os logs de processamento e dados associados por pelo menos um ano a partir da data de processamento, independentemente da cessação da finalidade. Isso serve para fins de auditoria e regulatórios. Portanto, para uma política prática de retenção de locais, aqui está a estrutura que eu recomendaria: reter perfis ativos de WiFi de visitantes pela duração do relacionamento mais um ano. Se um visitante não se conectar ou engajar por vinte e quatro meses, acione um fluxo de trabalho de novo consentimento ou exclusão. Mantenha os logs de processamento por no mínimo um ano. Para hóspedes de hotéis, a estadia cria uma relação de processamento legítima — mas o marketing pós-estadia exige consentimento separado, e esse consentimento tem seu próprio cronograma de retenção. Agora, transferências de dados transfronteiriças. Isso é na verdade mais simples sob a DPDP do que sob o GDPR. A lei usa uma abordagem de lista negra — as transferências são permitidas para todos os países, a menos que o Governo Central restrinja especificamente um país ou território específico por meio de notificação. Confronte isso com a abordagem de lista branca do GDPR, onde você precisa de uma decisão de adequação, Cláusulas Contratuais Padrão ou Regras Corporativas Vinculativas para cada transferência para um país não adequado. Para locais multinacionais que usam plataformas de WiFi baseadas em nuvem com data centers fora da Índia, você atualmente tem mais flexibilidade sob a DPDP — mas fique atento, pois os poderes de notificação do Governo significam que o cenário pode mudar. Deixe-me também cobrir os direitos que seus convidados têm sob a DPDP, porque suas equipes de TI e operações precisam ser capazes de responder a eles. Os Titulares dos Dados têm o direito de acessar informações sobre seu processamento, o direito de retificação e exclusão, e o direito de reparação de queixas — com uma janela de resposta obrigatória de noventa dias. O que eles não têm, ao contrário do GDPR, é o direito à portabilidade de dados, o direito de se opor à tomada de decisões automatizadas ou o direito à restrição do processamento. Esse é um framework de direitos mais estreito, o que simplifica um pouco suas obrigações de resposta. Os dados de crianças são uma categoria separada e de maior risco. Sob a DPDP, o consentimento parental verificável é exigido para o processamento de dados de qualquer pessoa menor de dezoito anos. Se o WiFi do seu estabelecimento estiver em um ambiente familiar — um shopping, um parque temático, um hotel familiar — você precisa de um mecanismo para identificar e lidar com usuários menores de idade. Este é um desafio técnico e operacional não trivial que muitos estabelecimentos ainda não abordaram. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS — 2 minutos] Deixe-me apresentar as três armadilhas mais comuns que vejo e como evitá-las. Armadilha um: consentimento agrupado. Esta é a violação mais frequente. Os estabelecimentos apresentam uma única caixa de seleção "Aceito os termos e condições" que cobre tanto o acesso à rede quanto o marketing. Sob a Seção 6 da DPDP, isso não está em conformidade. A correção é simples — separe seu consentimento em caixas de seleção distintas e específicas para cada finalidade, e garanta que a de marketing seja opcional e desmarcada por padrão. Armadilha dois: ausência de trilha de auditoria de consentimento. Se o Conselho de Proteção de Dados solicitar que você demonstre que um convidado específico deu consentimento em uma data específica para uma finalidade específica, você consegue apresentar esse registro? A maioria dos estabelecimentos não consegue. Sua plataforma de WiFi deve armazenar registros de consentimento com granularidade suficiente — carimbo de data/hora, ID da sessão, endereço IP, versão do consentimento e as finalidades específicas consentidas. A plataforma da Purple captura isso nativamente, mas se você estiver em um sistema legado, essa é uma lacuna que precisa fechar com urgência. Armadilha três: ausência de um acordo de processamento de dados. De acordo com a Seção 8(2), você deve ter um contrato válido com qualquer Processador de Dados que contratar. Se o seu provedor de plataforma WiFi não tiver um Acordo de Processamento de Dados atual que faça referência às obrigações da DPDP, você estará exposto. Isso não é apenas uma formalidade legal — é um pré-requisito para a defesa de conformidade do Fiduciário de Dados. Do lado da implementação, a principal decisão de arquitetura é onde os dados de consentimento são armazenados e como eles se integram ao seu CRM ou plataforma de automação de marketing. Você precisa de uma única fonte de verdade para o status do consentimento que sua equipe de marketing não possa anular. A revogação do consentimento deve se propagar para todos os sistemas downstream dentro de um prazo razoável — eu recomendaria um máximo de setenta e duas horas como seu SLA operacional. Para estabelecimentos com múltiplas propriedades — redes de hotéis, redes de varejo — você precisa decidir se o consentimento dado em uma propriedade se estende às outras. Sob o requisito de especificidade da DPDP, a posição mais segura é o consentimento no nível da propriedade, a menos que seu aviso cubra explicitamente o grupo e os hóspedes tenham consentido com o processamento em todo o grupo. [PERGUNTAS E RESPOSTAS RÁPIDAS — 1 minuto] Deixe-me passar por algumas perguntas que recebo regularmente. "Posso usar análises de WiFi — contagem de fluxo de pessoas, tempo de permanência — sem consentimento?" Se os dados forem genuinamente anonimizados e não puderem ser vinculados a um indivíduo, eles ficam fora do escopo da Lei DPDP. Mas a randomização de endereços MAC significa que o rastreamento no nível do dispositivo está cada vez mais não confiável de qualquer maneira. Para análises identificadas, você precisa de consentimento. "Preciso de um Encarregado de Proteção de Dados?" Um DPO completo é obrigatório apenas para Fiduciários de Dados Significativos — uma classificação que o Governo notificará. Para a maioria dos operadores de estabelecimentos, você precisa de uma pessoa responsável designada cujos detalhes de contato sejam publicados. Esse é um patamar mais baixo, mas ainda precisa ser alguém que possa realmente responder a perguntas sobre proteção de dados. "Qual é a exposição a penalidades para uma rede de hotéis de médio porte?" Uma falha de segurança que leve a uma violação acarreta até duzentos e cinquenta crore de rúpias. A não notificação da violação ao Conselho é de mais duzentos crore. Esses são limites fixos, não porcentagens de faturamento — o que significa que atingem organizações menores proporcionalmente com mais força do que as penalidades baseadas em faturamento do GDPR atingem grandes multinacionais. [RESUMO E PRÓXIMOS PASSOS — 1 minuto] Para encerrar, aqui estão suas cinco ações imediatas. Uma: audite seu fluxo de consentimento do Captive Portal hoje mesmo. Se ele tiver uma única caixa de seleção ou agrupar marketing com acesso, ele precisa ser reconstruído. Duas: implemente uma trilha de auditoria de consentimento. Cada evento de consentimento deve ser registrado com carimbo de data/hora, IP, finalidade e versão. Três: estabeleça uma política de retenção de dados. Para a maioria dos estabelecimentos, um gatilho de inatividade de vinte e quatro meses para novo consentimento ou exclusão é um ponto de partida razoável, com um mínimo de um ano para registros de processamento. Quatro: revise seus Acordos de Processamento de Dados com seu provedor de plataforma WiFi e quaisquer fornecedores downstream de marketing ou análise. Cinco: designe uma pessoa responsável por dúvidas de proteção de dados e publique seus detalhes de contato em seu Captive Portal e site. A Lei DPDP não é tão complexa quanto o GDPR em termos de amplitude de obrigações, mas é igualmente séria em termos de intenção de aplicação. O Conselho de Proteção de Dados tem dentes reais, e a estrutura de penalidades foi projetada para ser significativa mesmo para grandes organizações. Para um mergulho mais profundo na arquitetura de Captive Portal, os guias técnicos da Purple cobrem os detalhes de implementação minuciosamente. E se você está analisando como a análise de WiFi de visitantes se integra ao seu ecossistema mais amplo de inteligência de locais, a plataforma Purple WiFi Analytics foi construída com a captura de dados baseada em consentimento em seu núcleo. Obrigado por ouvir. Até a próxima.