India DPDP Act: Guest WiFi Compliance for Indian Venues

Lei DPDP da Índia: Conformidade do Guest WiFi para Espaços Indianos Um Briefing Técnico da Purple — Aproximadamente 10 Minutos [INTRODUÇÃO E CONTEXTO — 1 minuto] Bem-vindo ao Briefing Técnico da Purple. Sou o vosso anfitrião e hoje vamos aprofundar um tema que deve estar no radar de todos os diretores de TI e responsáveis de conformidade neste momento: a Lei de Proteção de Dados Pessoais Digitais da Índia — a Lei DPDP — e o que esta significa especificamente para implementações de guest WiFi em espaços indianos. Quer esteja a gerir uma cadeia de hotéis em Bombaim, uma rede de retalho em Bangalore, um estádio em Hyderabad ou a filial indiana de uma multinacional — se opera um guest WiFi e recolhe dados de registo através de um Captive Portal, esta legislação afeta-o diretamente. As regras estão em vigor, a fiscalização está a aumentar e as sanções são substanciais. Estamos a falar de até duzentos e cinquenta crore de rupias apenas por falhas de segurança. Por isso, vamos a isto. Nos próximos dez minutos, vou guiar-vos pelas principais obrigações, mostrar como isto difere do GDPR na prática, apresentar uma estrutura prática de retenção e alertar para os três erros mais comuns que os espaços estão a cometer neste momento. [APROFUNDAMENTO TÉCNICO — 5 minutos] Comecemos pelos fundamentos. A Lei de Proteção de Dados Pessoais Digitais foi promulgada em agosto de 2023, com as regras de aplicação finalizadas no final de 2025. Os prazos de conformidade estão a decorrer de forma faseada, entre doze a dezoito meses a partir da entrada em vigor das regras — por isso, se ainda não iniciou o seu programa de conformidade, já está atrasado. A primeira coisa a compreender é a terminologia. Ao abrigo da Lei DPDP, o seu espaço é o Fiduciário de Dados (Data Fiduciary) — decide por que razão e como os dados pessoais são processados. O seu fornecedor de plataforma de WiFi — quer seja a Purple ou qualquer outro fornecedor — é o Processador de Dados (Data Processor). E o seu convidado é o Titular dos Dados (Data Principal). Esta distinção é extremamente importante porque, ao abrigo da DPDP, ao contrário do GDPR, toda a responsabilidade de conformidade recai sobre o Fiduciário de Dados. O DPA do seu fornecedor de plataforma não transfere o seu risco. O risco é seu. Agora, o consentimento. É aqui que a maioria dos espaços se perde. O Artigo 6.º da Lei exige que o consentimento seja livre, específico, informado, incondicional e inequívoco, mediante uma ação afirmativa clara. Essa palavra "incondicional" é exclusiva da DPDP — não existe no GDPR — e tem dentes afiados. Significa que não pode tornar o consentimento de marketing uma condição para receber acesso ao WiFi. Ponto final.Como é que isso se traduz na prática num Captive Portal? Precisa de três coisas. Primeiro, um aviso em conformidade com a DPDP apresentado antes de qualquer recolha de dados — este deve indicar quais os dados que está a recolher, porquê, durante quanto tempo os irá guardar, como o visitante pode retirar o consentimento e como pode contactar o seu Encarregado de Proteção de Dados ou a pessoa responsável designada. Segundo, caixas de seleção de consentimento granulares: uma para o acesso à rede — que é o processamento necessário — e caixas de seleção separadas e opcionais para comunicações de marketing e análise ou definição de perfis. Estas devem estar desmarcadas por predefinição. Terceiro, deve registar o consentimento — carimbo de data/hora, endereço IP, versão do consentimento e exatamente o que foi acordado — e deve ser capaz de apresentar esse registo mediante pedido. Uma nota prática sobre o funcionamento do Captive Portal: se estiver a implementar em dispositivos Apple iOS, Android ou máquinas Windows, o Captive Network Assistant — ou CNA — comporta-se de forma diferente em cada plataforma. O CNA da Apple abre um mini-navegador que tem limitações em termos de cookies e redirecionamentos. Precisa de garantir que o seu mecanismo de consentimento funciona dentro dessas restrições. O guia da Purple sobre deteção de Captive Portal aborda a implementação técnica em detalhe — vale a pena ler em conjunto com este briefing de conformidade. Agora vamos falar sobre a retenção de dados, porque é aqui que vejo a maior confusão. A abordagem da lei DPDP é orientada para os fins. Ao abrigo da Secção 8(7), deve apagar os dados pessoais quando o Titular dos Dados retirar o consentimento ou quando a finalidade especificada já não estiver a ser cumprida — o que ocorrer primeiro. A Regra 8 adiciona depois duas sobreposições importantes. Primeiro, para certas plataformas de grande volume — comércio eletrónico com mais de vinte milhões de utilizadores, redes sociais, jogos online — o Terceiro Anexo estabelece um período de cessação presumida de três anos. Se não houver interação durante três anos, considera-se que a finalidade já não está a ser cumprida. Para a maioria dos operadores de espaços — hotéis, retalho, estádios — não se enquadrará nestas categorias específicas do Terceiro Anexo, pelo que aplica o princípio geral da Secção 8(8): se o visitante não interagiu consigo ou não exerceu os seus direitos durante um período razoável, deve apagar os seus dados. Segundo, a Regra 8(3) cria um limite mínimo: deve reter os registos de processamento e dados associados por, pelo menos, um ano a partir da data de processamento, independentemente da cessação da finalidade. Isto serve para fins de auditoria e regulamentares. Portanto, para uma política prática de retenção em espaços físicos, eis a estrutura que recomendo: reter os perfis ativos de WiFi de visitantes durante a vigência da relação mais um ano. Se um visitante não se ligar ou interagir durante vinte e quatro meses, ative um fluxo de trabalho de novo consentimento ou de eliminação. Mantenha os registos de processamento por um período mínimo de um ano. Para os hóspedes de hotéis, a estadia cria uma relação de processamento legítima — mas o marketing pós-estadia requer um consentimento separado, e esse consentimento tem o seu próprio prazo de retenção. Agora, as transferências transfronteiriças de dados. Isto é, na verdade, mais simples sob a DPDP do que sob o GDPR. A Lei utiliza 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 determinado país ou território por meio de notificação. Contraste isto com a abordagem de lista branca do GDPR, onde necessita de uma decisão de adequação, Cláusulas Contratuais-Tipo ou Regras Corporativas Vinculativas para cada transferência para um país não adequado. Para locais multinacionais que utilizam plataformas de WiFi baseadas na nuvem com centros de dados fora da Índia, tem atualmente mais flexibilidade sob a DPDP — mas fique atento, porque os poderes de notificação do Governo significam que o cenário pode mudar. Deixe-me também abordar os direitos que os seus convidados têm sob a DPDP, porque as suas equipas de TI e de operações precisam de ser capazes de responder aos mesmos. Os Titulares dos Dados têm o direito de aceder a informações sobre o seu tratamento, o direito de retificação e apagamento, e o direito de reparação de queixas — com uma janela de resposta obrigatória de noventa dias. O que não têm, ao contrário do GDPR, é o direito à portabilidade dos dados, o direito de oposição a decisões automatizadas ou o direito à limitação do tratamento. Trata-se de um quadro de direitos mais estreito, o que simplifica de certa forma as suas obrigações de resposta. Os dados de crianças são uma categoria separada e de maior risco. Sob a DPDP, é necessário o consentimento parental verificável para o tratamento de dados de qualquer pessoa com menos de dezoito anos. Se o WiFi do seu local estiver num ambiente familiar — um centro comercial, um parque temático, um hotel familiar — precisa de um mecanismo para identificar e gerir utilizadores menores. Este é um desafio técnico e operacional não trivial que muitos locais ainda não abordaram. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS — 2 minutos] Deixe-me apresentar-lhe os três erros mais comuns que vejo e como evitá-los. Erro um: consentimento agrupado. Esta é a violação mais frequente. Os locais apresentam uma única caixa de seleção "Aceito os termos e condições" que abrange tanto o acesso à rede como o marketing. Sob a Secção 6 da DPDP, isto não está em conformidade. A solução é simples — separe o seu consentimento em caixas de seleção distintas e específicas para cada finalidade, e garanta que a de marketing é opcional e não está selecionada por predefinição. Erro dois: ausência de registo de auditoria de consentimento. Se o Conselho de Proteção de Dados lhe pedir para demonstrar que um convidado específico deu o seu consentimento numa data específica para uma finalidade específica, consegue apresentar esse registo? A maioria dos locais não consegue. A sua plataforma de WiFi deve armazenar registos 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 capta isto de forma nativa, mas se estiver num sistema legado, esta é uma lacuna que precisa de colmatar urgentemente. Terceiro erro: ausência de um acordo de processamento de dados. Nos termos da Secção 8(2), deve ter um contrato válido com qualquer Processador de Dados que contrate. Se o seu fornecedor de plataforma WiFi não tiver um Acordo de Processamento de Dados atual que faça referência às obrigações do DPDP, está exposto. Isto 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 decisão arquitetónica fundamental é onde os dados de consentimento são armazenados e como se integram com o seu CRM ou plataforma de automação de marketing. Precisa de uma única fonte de verdade para o estado do consentimento que a sua equipa de marketing não possa anular. A retirada do consentimento deve propagar-se para todos os sistemas a jusante dentro de um prazo razoável — recomendaria um máximo de setenta e duas horas como o seu SLA operacional. Para locais com múltiplas propriedades — cadeias hoteleiras, complexos comerciais — precisa de decidir se o consentimento dado numa propriedade se estende às outras. Sob o requisito de especificidade do DPDP, a posição mais segura é o consentimento ao nível da propriedade, a menos que o seu aviso cubra explicitamente o grupo e os hóspedes tenham consentido no processamento a nível do grupo. [PERGUNTAS E RESPOSTAS RÁPIDAS — 1 minuto] Vou abordar rapidamente algumas perguntas que recebo regularmente. "Posso utilizar analítica de WiFi — contagem de visitantes, tempo de permanência — sem consentimento?" Se os dados forem genuinamente anonimizados e não puderem ser associados a um indivíduo, ficam fora do âmbito da Lei DPDP. Mas a aleatorização de endereços MAC significa que a monitorização ao nível do dispositivo é, de qualquer forma, cada vez mais não fiável. Para analítica identificada, 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 irá notificar. Para a maioria dos operadores de locais, precisa de uma pessoa responsável designada cujos dados de contacto sejam publicados. Esse é um patamar mais baixo, mas ainda assim precisa de ser alguém que possa realmente responder a questões de proteção de dados. "Qual é a exposição a penalizações para uma cadeia hoteleira de dimensão média?" Uma falha de segurança que leve a uma violação acarreta até duzentos e cinquenta crore de rupias. A não notificação da violação ao Conselho representa outros duzentos crore. Estes são limites máximos fixos, não percentagens de faturação — o que significa que afetam as organizações mais pequenas de forma proporcionalmente mais dura do que as penalizações baseadas na faturação do GDPR afetam as grandes multinacionais. [RESUMO E PRÓXIMOS PASSOS — 1 minuto] Para concluir, aqui estão as suas cinco ações imediatas. Primeira: audite hoje mesmo o fluxo de consentimento do seu Captive Portal. Se tiver uma única caixa de seleção ou agrupar o marketing com o acesso, precisa de ser reconstruído. Segunda: implemente um registo de auditoria de consentimento. Cada evento de consentimento deve ser registado com carimbo de data/hora, IP, finalidade e versão. Terceira: estabeleça uma política de retenção de dados. Para a maioria dos locais, um gatilho de inatividade de vinte e quatro meses para novo consentimento ou eliminação é um ponto de partida razoável, com um mínimo de um ano para os registos de processamento. Quarta: reveja os seus Acordos de Processamento de Dados com o seu fornecedor de plataforma WiFi e quaisquer fornecedores de marketing ou analítica a jusante. Cinco: designe uma pessoa responsável pelas questões de proteção de dados e publique os seus dados de contacto no seu Captive Portal e website. A Lei DPDP não é tão complexa como 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 penalizações foi concebida para ser significativa, mesmo para grandes organizações. Para um aprofundamento na arquitetura do Captive Portal, os guias técnicos da Purple cobrem os detalhes de implementação em pormenor. E se está a analisar como a análise de guest WiFi se integra com a sua pilha mais ampla de inteligência de espaços, a plataforma Purple WiFi Analytics foi construída com a captura de dados baseada no consentimento em primeiro lugar no seu núcleo. Obrigado por ouvir. Até à próxima.