GDPR and WiFi: A Compliance Guide for Businesses

GDPR E WIFI: UM GUIA DE CONFORMIDADE PARA EMPRESAS Uma Sessão de Informação Purple — aproximadamente 10 minutos [INTRODUÇÃO E CONTEXTO — 1 minuto] Bem-vindo à Sessão de Informação Purple. Sou o seu anfitrião e hoje vamos directos ao assunto sobre um dos desafios de conformidade mais incompreendidos que os operadores de espaços e as equipas de TI enfrentam actualmente: GDPR e WiFi. Se disponibiliza WiFi para convidados num complexo hoteleiro, numa cadeia de retalho, num estádio ou num edifício do sector público — está a recolher dados pessoais. Ponto final. E, quer se aperceba ou não, essa recolha está sujeita ao Regulamento Geral sobre a Proteção de Dados. O ICO tem estado cada vez mais activo nesta área e as consequências de errar vão desde avisos de infração até coimas que podem atingir quatro por cento do volume de negócios anual global. Mas a verdade é esta — a conformidade com o GDPR para WiFi não é tão complicada como as equipas jurídicas por vezes fazem parecer. Resume-se a quatro questões fundamentais: Que dados está a recolher? Com que base jurídica? Durante quanto tempo os vai guardar? E quem é o responsável? Responda correctamente a estas quatro perguntas e terá a maior parte do caminho percorrido. Vamos a isso. [ANÁLISE TÉCNICA DETALHADA — 5 minutos] Então, comecemos pelos dados que uma implementação típica de WiFi para convidados realmente recolhe. Quando um convidado se liga à sua rede através de um Captive Portal — que é a página de boas-vindas que visualizam antes de terem acesso à internet — está potencialmente a capturar um endereço MAC, um endereço IP, um registo de data/hora da ligação, a duração da sessão e, se tiver integrado um fluxo de registo, um endereço de email, um nome e preferências de marketing. Ora, os endereços MAC e os endereços IP são classificados como dados pessoais ao abrigo do GDPR porque podem ser utilizados para identificar um indivíduo. Isto surpreende muitos arquitectos de rede. Pensam neles como identificadores técnicos e não como dados pessoais. Mas o regulamento é claro: se puder ser utilizado, directa ou indirectamente, para identificar uma pessoa singular, trata-se de dados pessoais. Portanto, os registos da sua rede estão abrangidos desde o momento em que um dispositivo se liga. A questão seguinte é a base jurídica. Ao abrigo do Artigo 6.º do GDPR, necessita de uma de seis bases jurídicas para tratar dados pessoais. Para o WiFi para convidados, as duas que mais importam são o consentimento e os interesses legítimos. O consentimento é a opção mais transparente quando está a recolher endereços de email para fins de marketing. Ao abrigo do GDPR, o consentimento deve ser livremente dado, específico, informado e inequívoco. Isso significa que não pode haver caixas pré-seleccionadas. Nada de associar o consentimento de marketing aos termos e condições. O convidado deve aceitar activamente (opt-in) e o utilizador deve ser capaz de demonstrar que o fez — com um registo de data/hora e um registo daquilo com que consentiu nesse momento específico. Os interesses legítimos são a base que a maioria dos operadores utiliza para os dados subjacentes de ligação à rede — aspetos como endereços MAC e registos de sessão. O argumento é que a operação de uma rede segura e funcional é um interesse legítimo da empresa, e esse interesse não é sobreposto pelos direitos de privacidade do indivíduo. Mas — e isto é importante — ainda precisa de realizar e documentar uma Avaliação de Interesses Legítimos (LIA). Não pode apenas alegar interesses legítimos e seguir em frente. O ICO espera ver o teste de três partes: finalidade, necessidade e ponderação. Agora vamos falar sobre o design da splash page, porque é aqui que a maioria das organizações falha. A splash page é a sua interface principal de consentimento e precisa de fazer várias coisas em simultâneo. Precisa de identificar quem está a recolher os dados — que é o nome da sua organização. Precisa de explicar quais os dados que estão a ser recolhidos e porquê. Precisa de apresentar qualquer opção de adesão a marketing como uma caixa de seleção separada e desmarcada. E precisa de ligar a um aviso de privacidade completo que cubra os direitos dos titulares dos dados. O que não deve fazer é tornar o acesso à rede condicionado ao consentimento de marketing. Se bloquear o WiFi atrás de um registo de e-mail onde a única forma de se ligar é aceitar receber e-mails de marketing, esse consentimento não é dado livremente ao abrigo do GDPR. O ICO tem sido explícito sobre isto. Pode oferecer um incentivo para o fornecimento de um endereço de e-mail — um ponto de fidelidade, um cupão de desconto — mas o acesso básico à rede deve estar disponível independentemente disso. Passando para a retenção de dados. O Artigo 5(1)(e) do GDPR estabelece o princípio da limitação da conservação: os dados pessoais não devem ser mantidos por mais tempo do que o necessário para a finalidade para a qual foram recolhidos. Para o WiFi de convidados, isso significa que precisa de um calendário de retenção documentado. Os registos de segurança de rede — aspetos como endereços MAC e carimbos de data/hora de sessão — são normalmente retidos por 90 dias para fins de investigação de segurança e fraude. Essa é uma posição defensável. Os endereços de e-mail recolhidos para marketing podem ser retidos por mais tempo, mas precisa de definir esse período, comunicá-lo no seu aviso de privacidade e aplicá-lo tecnicamente — não apenas como uma política no papel. É aqui que a stack tecnológica importa. Uma plataforma como a solução de WiFi de convidados da Purple automatiza a aplicação da retenção. Configura uma janela de retenção e o sistema elimina os registos automaticamente. Essa é a diferença entre uma política de conformidade e um programa de conformidade. A política diz o que vai fazer. O programa prova que o fez. Vamos falar sobre Acordos de Processamento de Dados, ou DPAs. Se está a utilizar uma plataforma de terceiros para gerir o seu WiFi de convidados — o que acontece na maioria das organizações — essa plataforma está a agir como subcontratante em seu nome. Ao abrigo do Artigo 28.º do GDPR, deve ter um Acordo de Processamento de Dados por escrito com esse subcontratante. O DPA deve especificar que dados estão a ser processados, com que finalidade, sob que instruções e que medidas de segurança o subcontratante tem implementadas. Se está a utilizar uma plataforma de analítica de WiFi baseada na nuvem e não tem um DPA assinado, não está em conformidade. É tão simples quanto isso. Para organizações que operam em vários estados-membros da UE ou que servem residentes da UE a partir de uma base no Reino Unido pós-Brexit, também precisa de considerar o GDPR do Reino Unido — que é essencialmente o GDPR da UE retido na lei do Reino Unido — e se existem transferências internacionais de dados envolvidas. Se a sua plataforma de WiFi armazena dados em servidores fora do Reino Unido ou do EEE, precisa de um mecanismo de transferência adequado: uma decisão de adequação, cláusulas contratuais-tipo ou regras vinculativas aplicáveis às empresas. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS — 2 minutos] Muito bem, vamos à prática. Aqui estão os quatro passos de implementação que recomendaria a qualquer equipa de TI ou operador de espaço que esteja a iniciar este processo. Primeiro: realize um exercício de mapeamento de dados. Antes de tocar na sua página de login (Captive Portal) ou no seu aviso de privacidade, mapeie cada dado que a sua implementação de WiFi recolhe, para onde vai, quem tem acesso e durante quanto tempo é guardado. Este é o seu Registo de Atividades de Tratamento ao abrigo do Artigo 30.º, e é a base de tudo o resto. Segundo: audite a sua página de login (Captive Portal) face aos requisitos de consentimento. Verifique se existem caixas pré-selecionadas. Confirme se o consentimento de marketing está separado da aceitação dos termos. Verifique se a ligação para o seu aviso de privacidade está visível e funcional. Se estiver a utilizar uma plataforma como a Purple, as ferramentas de gestão de consentimento já estão integradas — mas ainda assim precisa de as configurar corretamente e rever o texto. Terceiro: garanta que os seus DPAs estão em vigor. Contacte todos os fornecedores terceiros que tocam nos seus dados de WiFi — o seu fornecedor de plataforma, a sua ferramenta de analítica, o seu CRM — e confirme que existe um DPA assinado. Se não existir, obtenha um antes de avançar. Quarto: implemente controlos técnicos de retenção. Não dependa de processos manuais para eliminar dados antigos. Configure a eliminação automatizada na sua plataforma e documente a configuração como prova de conformidade. O erro mais comum que vejo é as organizações tratarem o GDPR como um projeto único e não como um programa contínuo. Fazem a auditoria, atualizam a página de login (Captive Portal), arquivam o DPA e, dois anos mais tarde, a plataforma foi atualizada, o texto da página de login foi alterado pela equipa de marketing e ninguém reviu as definições de retenção. A conformidade com o GDPR exige um ciclo de revisão periódico — no mínimo anualmente, e sempre que ocorra uma alteração significativa nas suas atividades de processamento de dados. [PERGUNTAS E RESPOSTAS RÁPIDAS — 1 minuto] Algumas perguntas que me fazem regularmente. "Precisamos de um DPO?" — Se for uma autoridade pública ou se as suas atividades principais envolverem a monitorização sistemática de indivíduos em grande escala — o que uma grande implementação de guest WiFi pode qualificar — então sim, precisa de um Encarregado de Proteção de Dados designado. Para implementações mais pequenas, é uma boa prática, mesmo que não seja estritamente obrigatório. "Podemos usar endereços MAC para análise de tráfego de visitantes?" — Sim, mas apenas se estiver a utilizar dados anonimizados ou agregados. Se estiver a monitorizar endereços MAC individuais ao longo de sessões para criar perfis de movimento, isso constitui processamento de dados pessoais e necessita de uma base jurídica e de uma divulgação na política de privacidade. "E em relação às crianças?" — Se o seu espaço for propício a ser acedido por crianças com menos de 13 anos, deve considerar o Children's Code do ICO. Isso significa que não deve haver criação de perfis comportamentais de crianças e que as políticas de privacidade devem ser adequadas à idade. [RESUMO E PRÓXIMOS PASSOS — 1 minuto] Para concluir: a conformidade do GDPR e WiFi é perfeitamente alcançável. O regulamento não foi concebido para o impedir de gerir um serviço de guest WiFi ou de recolher dados para melhorar as suas operações. Foi concebido para garantir que, quando recolhe dados, o faz de forma transparente, com uma base jurídica válida, com a segurança adequada e respeitando os direitos dos indivíduos. As quatro conclusões a retirar desta sessão: estabeleça a sua base jurídica e documente-a; desenhe a sua splash page para obter um consentimento genuíno; assine os seus DPAs; e aplique a retenção de forma técnica, não apenas no papel. Se quiser aprofundar qualquer uma destas áreas, a Purple dispõe de um conjunto completo de guias de implementação sobre recolha de dados primários (first-party data) através de WiFi, e a própria plataforma foi concebida para suportar implementações em conformidade com o GDPR de forma nativa. Obrigado por ouvir. Até à próxima.