Requisitos de RFP para WiFi para visitantes: o que especificar em integração, segurança e analíticos

Uma RFP de WiFi para visitantes deve definir requisitos mensuráveis em cinco áreas. Integração: portal cativo, captura de consentimento e acessibilidade WCAG 2.2. Segurança: IEEE 802.1X, RADIUS, Passpoint e WPA3. Hardware: suporte nomeado para Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist e Ubiquiti UniFi. Conformidade: GDPR, PCI DSS v4.0 e DNS de proteção. Análise: dados próprios exportáveis. Pontue os licitantes com base em evidências.

O que uma RFP de WiFi para visitantes realmente precisa especificar?

Uma RFP de WiFi para visitantes transforma um briefing vago, como "WiFi gratuito para visitantes", em requisitos nos quais o licitante pode ser aprovado ou reprovado. Ela define como as pessoas se conectam, como o tráfego é protegido e em qual hardware a plataforma deve ser executada. Também estabelece como os dados pessoais são tratados e quais relatórios você recebe de volta.

RFPs fracas tendem a falhar da mesma maneira. Elas listam recursos em vez de padrões, para que todos os licitantes respondam "sim" e as respostas pareçam idênticas. A solução é anexar um padrão nomeado, a evidência esperada e um teste piloto a cada linha.

Para uma propriedade com vários locais, a RFP também estabelece seu modelo operacional pela duração do contrato. Um portal cativo é a página da web que um dispositivo visualiza antes de obter acesso à internet. Você pode executar um portal cativo e um registro de consentimento em todos os locais. A alternativa é uma configuração diferente para cada fornecedor de hardware. Desfazer uma propriedade fragmentada mais tarde custa muito mais do que especificar uma única agora.

Este guia oferece a redação dos requisitos, uma matriz de pontuação e testes piloto. Trate-o como um modelo de RFP de WiFi para visitantes que você pode adaptar para Hotéis, Varejo, Saúde, Trens, estádios e locais do setor público.

Do que você precisa antes de escrever a RFP de WiFi para visitantes?

Reúna cinco insumos antes do primeiro rascunho. Cada um deles previne uma fonte comum de solicitações de alteração após a adjudicação.

• Um inventário de hardware por local. Registre o fornecedor do ponto de acesso (AP), o modelo, a plataforma de gerenciamento e o firmware em todos os locais. Observe se cada local usa um painel na nuvem ou um controlador local. Nosso guia O que é um WLC (Wireless LAN Controller) e você ainda precisa de um? explica a diferença.
• Uma lista de locais por tipo. Agrupe os locais por setor e tamanho, pois o saguão de um estádio e a recepção de um hotel precisam de integrações diferentes. Nomeie as pessoas que cada local atende: convidados, compradores, passageiros, torcedores, pacientes ou visitantes.
• Um mapa de dados. Decida quem atua como controlador de dados, quais sistemas receberão os dados do WiFi e por quanto tempo você os manterá. Seu encarregado de proteção de dados deve aprovar isso antes do envio da RFP.
• Seus limites de pagamento. Liste todos os sites que aceitam pagamentos com cartão. Observe se os dispositivos de pagamento compartilham switches ou circuitos com o tráfego de visitantes. Isso define o escopo do seu PCI DSS.
• Métricas de sucesso. Acorde os números que você reportará, como logins, taxa de opt-in, visitantes recorrentes e chamados de suporte. Os fornecedores poderão então demonstrar como seus relatórios geram cada um desses dados.

Envolva as equipes de TI, segurança, proteção de dados, marketing e operações do local desde o início. O WiFi para visitantes engloba todas as cinco equipes. Um requisito definido por uma equipe frequentemente bloqueia outra.

Como escrever requisitos de RFP para WiFi para visitantes, seção por seção?

Escreva cada requisito utilizando "deve" ou "deveria", seguindo a convenção da RFC 2119. Um "deve" é um critério eliminatório de aprovação ou reprovação. Um "deveria" é pontuado. Solicite que os fornecedores respondam a cada linha com evidências: um documento, um certificado, um local de referência ou uma demonstração ao vivo.

Requisitos de integração e portal cativo

A integração é o momento em que os visitantes julgam sua rede e onde seus registros de consentimento são criados. Esta checklist de RFP para portal cativo cobre os pontos essenciais.

• Métodos de login. A plataforma deve suportar e-mail, login por redes sociais, SMS e códigos de acesso, configuráveis por local.
• Opt-ins de escolha consciente. O consentimento de marketing deve ser uma opção separada e desmarcada, nunca vinculada à aceitação dos termos. O Artigo 7 do GDPR exige que o consentimento seja demonstrável e tão fácil de retirar quanto de fornecer.
• Acessibilidade. O portal cativo deve atender ao padrão WCAG 2.2 nível AA.
• Detecção confiável de portal. A plataforma deveria suportar a API de Portal Cativo API (RFC 8908) e a opção de portal cativo DHCP (RFC 8910). Ambas ajudam os dispositivos modernos a encontrar a página de login sem loops de redirecionamento.
• Reconhecimento de visitantes recorrentes. O iOS 14 e o Android 10 em diante usam endereços MAC aleatórios por padrão. Pergunte aos fornecedores como eles reconhecem um visitante recorrente sem depender do endereço físico do dispositivo.
• Controle central. A matriz deve gerenciar a identidade visual, os termos e o texto de consentimento de forma centralizada, com permissões de sobreposição local para cada estabelecimento.

O Purple WiFi para visitantes integra opt-ins de escolha consciente no portal cativo e realiza o gerenciamento de forma centralizada em toda a rede de locais.

Requisitos de autenticação, RADIUS e Passpoint

O RADIUS é o protocolo que um AP utiliza para perguntar a um servidor central se deve permitir o acesso de um dispositivo. Ele é definido na RFC 2865. O accounting RADIUS, definido na RFC 2866, registra o início, o término e o uso de dados da sessão. Para uma rede com múltiplos locais, especifique o seguinte.

• RADIUS em nuvem com redundância. A autenticação deve continuar funcionando mesmo se um data center falhar. Solicite a arquitetura e os dados de disponibilidade mensurada dos últimos 12 meses.
• Transporte RADIUS criptografado. Onde o RADIUS trafegar pela internet pública, exija RadSec (RADIUS sobre TLS, RFC 6614) ou um túnel criptografado.
• Autorização dinâmica. A plataforma deveria enviar mensagens CoA (RFC 5176) para encerrar ou alterar uma sessão sem forçar uma reconexão.
• Segmentação. O tráfego de convidados deve ficar em sua própria VLAN, um segmento lógico de rede isolado dos sistemas de colaboradores e de pagamento. O isolamento de clientes deve impedir que os dispositivos de convidados alcancem uns aos outros.
• Criptografia em redes abertas. Exija WPA3, incluindo Enhanced Open (Opportunistic Wireless Encryption, RFC 8110). Ele criptografa cada conexão sem uma senha compartilhada.
• Chaves individuais onde necessário. O iPSK (identity pre-shared key) fornece a cada pessoa ou dispositivo sua própria senha de WiFi em uma rede compartilhada. É ideal para hóspedes de longa permanência, expositores e equipes de eventos. O Purple oferece isso por meio do SecurePass.

O Passpoint, também chamado de Hotspot 2.0, é baseado no IEEE 802.11u. Ele permite que um dispositivo encontre e entre em uma rede automaticamente, sem portal cativo. A autenticação é executada sobre o IEEE 802.1X, o padrão para controle de acesso à rede baseado em porta, mantendo as credenciais criptografadas. O OpenRoaming, administrado pela Wireless Broadband Alliance, é uma federação baseada no Passpoint. Ele permite que as pessoas acessem redes participantes com uma identidade que já possuem.

Especifique o Passpoint e o OpenRoaming como requisitos desejáveis na primeira fase, com um cronograma detalhado de custos. O Purple oferece suporte ao OpenRoaming, para que convidados recorrentes possam se conectar automaticamente em seus locais.

Se a RFP também cobrir o WiFi para colaboradores WiFi, exija integração com Microsoft Entra ID, Okta e Google Workspace. Isso mantém as admissões, transferências e desligamentos em sintonia com o acesso à rede, sem alterações manuais de senha.

Compatibilidade de AP neutra em relação ao hardware

"Compatível com o principal hardware corporativo" não pode ser pontuado. Nomeie cada plataforma que você opera ou possa adotar durante o contrato. Em seguida, exija os mesmos cinco recursos em cada uma delas.

1. Suporte a portal cativo externo.
2. Autenticação e contabilização RADIUS.
3. Walled garden: a lista de domínios permitidos pré-login necessária para o portal e para o login por redes sociais.
4. Suporte a CoA, ou uma alternativa documentada para encerrar sessões.
5. Um guia de integração publicado e pelo menos uma referência ativa nessa plataforma.

Fornecedor	Plataforma de gerenciamento a ser citada na RFP	Evidência mínima a ser solicitada
Cisco Meraki	Dashboard do Meraki	Guia de integração, referência ativa, piloto em seu firmware
HPE Aruba	HPE Aruba Networking Central ou Mobility Controller	Guia de integração, referência ativa, piloto em seu firmware
Ruckus	RUCKUS SmartZone ou RUCKUS One	Guia de integração, referência ativa, piloto em seu firmware
Juniper Mist	Nuvem da Juniper Mist	Guia de integração, referência ativa, piloto em seu firmware
Ubiquiti UniFi	Aplicativo de rede UniFi	Guia de integração, referência ativa, piloto em seu firmware
Cambium	cnMaestro	Guia de integração, referência ativa, piloto em seu firmware
Extreme	ExtremeCloud IQ	Guia de integração, referência ativa, piloto em seu firmware
Fortinet	Controlador sem fio integrado FortiGate	Guia de integração, referência ativa, piloto em seu firmware

Peça a cada licitante que informe as faixas de firmware suportadas e, em seguida, teste com as suas próprias. O Purple é agnóstico em relação ao hardware e roda como uma sobreposição em nuvem em todas as oito plataformas. Não há necessidade de substituição completa de infraestrutura. O artigo Por que sua próxima atualização de WiFi não precisa de novo hardware aborda o aspecto comercial. Para ambientes Ruckus, consulte Ruckus SmartZone e RUCKUS One guest WiFi vs plataformas externas de Captive Portal.

Cláusulas do GDPR a serem exigidas

O WiFi para visitantes coleta dados pessoais em escala, portanto, o contrato deve conter estas cláusulas.

• Um acordo de processamento de dados que atenda ao Artigo 28 do GDPR, cobrindo finalidade, segurança, subprocessadores e exclusão.
• Registros de consentimento mostrando carimbo de data/hora, versão do texto e canal para cada opt-in, exportáveis sob demanda.
• Retenção configurável com exclusão automática, em conformidade com o princípio de limitação de armazenamento do Artigo 5(1)(e).
• Ferramentas de titular dos dados para localizar, exportar e apagar os dados de uma pessoa. Você deve responder às solicitações em até um mês, de acordo com o Artigo 12(3).
• Notificação de violação por parte do processador sem demora injustificada, conforme exige o Artigo 33(2). Você tem 72 horas para notificar o órgão regulador de acordo com o Artigo 33(1).
• Transferências internacionais. O licitante deve declarar onde os dados são mantidos e o mecanismo de transferência para qualquer processamento fora do Reino Unido ou do EEE.
• Comprovação de segurança para o Artigo 32, idealmente com certificação ISO 27001.

O Purple possui certificação ISO 27001 e conformidade com GDPR, CCPA e Cyber Essentials.

Cláusulas do PCI-DSS a serem exigidas

O WiFi para visitantes nunca deve estar dentro do seu ambiente de dados de titulares de cartão (CDE). O CDE engloba os sistemas que armazenam, processam ou transmitem dados de cartão. O PCI-DSS v4.0 permite reduzir o escopo por meio da segmentação, mas você deve provar que ela funciona.

• O licitante deve confirmar por escrito que o tráfego de visitantes nunca atravessa o CDE e documentar a arquitetura.
• A arquitetura deve dar suporte ao seu teste de intrusão para segmentação, exigido pelo menos a cada 12 meses sob o requisito 11.4.5.
• Nenhum dado de cartão pode ser inserido no Captive Portal. Qualquer acesso pago deve usar um provedor de pagamento compatível com PCI-DSS, com seu Atestado de Conformidade fornecido.
• Seus testes trimestrais para pontos de acesso sem fio não autorizados sob o requisito 11.2.1 ainda cobrem as áreas de visitantes.

Cláusulas de DNS protetivo a serem exigidas

O DNS protetivo impede que os dispositivos resolvam domínios conhecidos por hospedar malware, phishing ou servidores de comando e controle. O National Cyber Security Centre (NCSC) do Reino Unido oferece um serviço de DNS protetivo para órgãos do setor público. Especifique o seguinte.

• Feeds de ameaças. O licitante deve declarar suas fontes de inteligência contra ameaças e a frequência com que são atualizadas.
• Filtragem por categoria por local, por exemplo, bloqueando conteúdo adulto em bibliotecas e áreas familiares.
• Uma página de bloqueio personalizada que informa ao visitante o motivo pelo qual um site foi bloqueado.
• Política de DNS criptografado. Especifique como o serviço lida com DNS sobre HTTPS (RFC 8484) e DNS sobre TLS (RFC 7858), que podem burlar a filtragem.
• Retenção de logs alinhada ao seu cronograma de GDPR. Logs de DNS vinculados a uma identidade autenticada são dados pessoais.
• Relatórios mensais de ameaças bloqueadas por local.

Os complementos de segurança da Purple são o SecurePass, o Verify e o Shield. Solicite uma demonstração de cada um em relação às cláusulas acima.

Requisitos de analítica e integração

A aquisição de WiFi para visitantes corporativo frequentemente subestima a analítica, embora seja nela que você percebe o retorno. Especifique o seguinte.

• Métricas por local e propriedade: visitantes únicos, visitantes novos versus recorrentes, tempo de permanência, frequência de visitas e horários de pico.
• Painéis e relatórios agendados, com acesso baseado em funções para que os gerentes de cada local vejam apenas o seu próprio site.
• Integrações com suas plataformas de CRM e marketing, por meio de API ou conectores nativos. O status do consentimento deve acompanhar cada registro.
• Propriedade dos dados. Você é o proprietário dos dados próprios. A exportação completa em CSV ou JSON deve estar disponível a qualquer momento e no encerramento do contrato, sem custo extra.

O Purple WiFi Analytics relata essas métricas por local e se integra a plataformas de CRM e marketing.

Níveis de serviço e certificações

• Disponibilidade. Exija um SLA de tempo de atividade mensal com créditos de serviço. A plataforma da Purple opera com 99,999% de tempo de atividade.
• Suporte. Especifique horários, tempos de resposta por gravidade e um contato de escalonamento designado.
• Certificações. Exija ISO 27001. Contratos do governo central do Reino Unido que tratam de dados pessoais exigem Cyber Essentials, de acordo com a Nota de Política de Aquisição 09/14.
• Referências de escala. Solicite referências compatíveis com o seu porte. A Purple opera em mais de 80.000 locais ativos em mais de 90 países e gerenciou 440 milhões de logins em 2024 (dados próprios da Purple).

Matriz de pontuação de requisitos

Área	Requisito	Prioridade	Evidência a solicitar
Onboarding	Opt-in de marketing separado e desmarcado	Obrigatório	Capturas de tela do portal e uma amostra de exportação de consentimento
Onboarding	Portal cativo WCAG 2.2 AA	Obrigatório	Relatório de auditoria de acessibilidade independente
Autenticação	RADIUS em nuvem com failover	Obrigatório	Diagrama de arquitetura e 12 meses de dados de disponibilidade
Autenticação	RadSec ou túnel RADIUS criptografado	Obrigatório	Documento de design
Autenticação	Passpoint e OpenRoaming	Recomendável	Site de referência ativo
Criptografia	WPA3 e Enhanced Open	Recomendável	Teste piloto em seus APs
Hardware	Suporte nominal para cada plataforma em uso	Obrigatório	Guia de integração e resultado do piloto
GDPR	DPA do Artigo 28 e controles de retenção	Obrigatório	DPA assinado e demonstração das configurações de retenção
PCI DSS	Tráfego de visitantes fora do CDE	Obrigatório	Design de segmentação e declaração de suporte a testes
DNS de Proteção	Filtragem de ameaças e categorias com página de bloqueio	Obrigatório para o setor público, recomendável nos demais casos	Teste de bloqueio ao vivo e amostra de relatório mensal
Análise de dados	Exportação completa de dados no encerramento	Obrigatório	Cláusula contratual e amostra do arquivo de exportação
Serviço	SLA de disponibilidade com créditos de serviço	Obrigatório	Cronograma de SLA

Como verificar se um licitante pode entregar o que foi prometido?

Avalie em duas etapas: documental e, em seguida, piloto. Qualquer item "obrigatório" não atendido elimina o licitante na etapa documental. Pondere as linhas "desejáveis" restantes para corresponder às suas prioridades. Uma divisão típica é: segurança e conformidade 30%, integração 20%, hardware 15%, análise de dados 15%, serviço 10% e comercial 10%.

Execute um piloto de 30 dias em dois ou mais locais com diferentes plataformas de hardware. Teste cada um destes itens e registre a aprovação ou reprovação.

• O portal cativo é exibido de primeira no iOS, Android, Windows e macOS.
• Um visitante recorrente é reconhecido em uma segunda visita.
• Uma exportação de consentimento mostra o carimbo de data/hora e a versão do texto.
• Uma solicitação de exclusão remove a pessoa da plataforma e do seu CRM conectado.
• A autenticação continua durante uma falha simulada do RADIUS.
• Uma mensagem CoA encerra uma sessão sem reconexão.
• Um domínio de teste conhecido é bloqueado, exibindo sua página personalizada.
• Uma tentativa de conexão do VLAN para a rede de pagamento falha.

Teste o rendimento e a cobertura separadamente da plataforma. O artigo WiFi para a internet: Como funciona e o que verificar cobre os conceitos básicos.

Como isso se parece na prática?

Os três cenários abaixo são composições ilustrativas criadas a partir de padrões comuns de aquisição. Eles não são estudos de caso de clientes.

Um grupo de 45 hotéis em duas plataformas de hardware

Situação. O grupo utilizava Cisco Meraki em 30 hotéis e HPE Aruba em 15 locais adquiridos. Cada propriedade tinha seu próprio portal cativo. Nos 15 locais adquiridos, o consentimento de marketing estava vinculado à aceitação dos termos.

O que foi feito. O RFP definiu ambas as plataformas como requisitos "obrigatórios". Foi exigido um único portal, um registro de consentimento unificado e opt-ins separados. O piloto cobriu um hotel em cada plataforma.

Resultado. Dois dos cinco licitantes falharam na etapa de hardware porque ofereciam suporte a apenas uma plataforma. A solução vencedora manteve todos os 15 locais com Aruba em seus APs existentes. O consentimento vinculado foi removido em todos os 15 locais antes do lançamento.

Uma rede de varejo de 120 lojas no escopo do PCI DSS

Situação. Os terminais de pagamento compartilhavam switches com APs de visitantes em lojas mais antigas. O WiFi para visitantes estava, portanto, dentro da avaliação PCI DSS da rede.

O que foi feito. O RFP exigiu um projeto de segmentação documentado e suporte por escrito para o teste de penetração 11.4.5. Também proibiu a inserção de dados de cartão no portal cativo.

Resultado. O teste anual de segmentação foi aprovado em todas as 120 lojas. O WiFi para visitantes saiu do escopo do PCI DSS, o que reduziu os sistemas que o avaliador precisava revisar.

Um conselho municipal com 25 bibliotecas e centros de lazer

Situação. O conselho precisava de WiFi público seguro para famílias, Cyber Essentials e uma página de login acessível.

O que foi feito. O DNS de proteção era indispensável, com filtragem de categorias para áreas infantis e uma política de DNS criptografado. Os logs de DNS foram mantidos por 90 dias, de acordo com o cronograma de retenção do conselho.

Resultado. Três dos sete licitantes não passaram no critério da WCAG 2.2. No piloto, a filtragem de um dos licitantes pré-selecionados foi burlada por meio do DNS sobre HTTPS, o que o eliminou da disputa.

O que dá errado na aquisição de WiFi para visitantes e como corrigir?

Todos os licitantes respondem "sim"

Causa: os requisitos descrevem recursos, não padrões. Solução: especifique o RFC, o padrão IEEE ou o artigo da GDPR para cada linha e exija comprovações.

O portal cativo não aparece

Causa: um jardim murado incompleto ou detecção fraca de portal cativo. Solução: exija suporte aos padrões RFC 8908 e RFC 8910 e teste quatro sistemas operacionais no piloto.

O número de visitantes parece inflado

Causa: endereços MAC aleatórios fazem com que um único dispositivo pareça vários. Solução: exija o reconhecimento com base na identidade de login e peça aos licitantes que expliquem como contam os visitantes recorrentes.

O consentimento não se sustenta

Causa: autorizações agrupadas com termos de uso ou ausência de registro do texto exibido. Solução: exija autorizações separadas e desmarcadas por padrão, além de registros de consentimento com controle de versão.

Você não consegue cancelar

Causa: ausência de cláusula de exportação de dados. Solução: exija a exportação completa em CSV ou JSON no encerramento do contrato, sem custo adicional.

O contrato força a compra de novos hardwares

Causa: um fornecedor vinculado a uma única marca de AP. Solução: uma cláusula de neutralidade de hardware que especifique todas as plataformas que você utiliza.

Quanto custa e qual é o retorno?

Faça o orçamento para seis linhas de custo: licenças de software, hardware eventual, instalação, circuitos de internet, suporte e o tempo da sua própria equipe. A arquitetura escolhida é o fator determinante para a maior parte da variação de custos.

Abordagem	Custo de hardware	Infraestrutura multifornedora	Consentimento e dados	Alteração em cada local
Sobreposição em nuvem nos APs existentes (Purple)	Nenhum: executa nos APs existentes	Um único portal em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet	Registros de consentimento centralizados e dados próprios pertencentes a você	Configuração de SSID e RADIUS nos APs existentes
Portal cativo integrado do fornecedor do AP	Nenhum na plataforma atual	Um portal separado para cada plataforma de hardware	Consentimento e dados de visitantes mantidos separadamente em cada plataforma	Configuração repetida em cada plataforma
Substituição completa da rede gerida	Novos APs e licenças em cada local	Um único fornecedor de hardware imposto em toda a infraestrutura	Definido pelos termos do contrato do provedor	Instalação de novos APs em cada local

Peça aos licitantes que apresentem propostas com base em um critério único: um preço anual fixo por local para todo o período contratual. Exija que a integração, o suporte, as atualizações e os custos de encerramento sejam detalhados por item. A Purple fornece orçamentos com base em três planos, Connect, Capture e Engage, com SecurePass, Verify e Shield como complementos de segurança.

O retorno vem de quatro lugares. Você obtém dados próprios com respaldo de consentimento legal. Você visualiza horários de pico e tempo de permanência para planejar a alocação da equipe. Você evita gastos com hardware por meio da sobreposição. Você obtém uma única plataforma para dar suporte em vez de várias. A Purple entrega isso desde 2012, em mais de 80.000 locais ativos.

Perguntas frequentes

Uma plataforma de WiFi para visitantes pode ser executada nos pontos de acesso que já possuímos?

Sim. A Purple é agnóstica em relação ao hardware e é executada como uma sobreposição na nuvem na Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Seus APs continuam gerenciando a rádio e o tráfego. A Purple fornece o portal cativo, o RADIUS na nuvem, registros de consentimento e análises. Em sua RFP, cite todas as plataformas que você utiliza e exija um piloto em seu próprio firmware antes da adjudicação.

Como devemos solicitar aos fornecedores que precifiquem o WiFi para visitantes em uma RFP?

Peça um preço anual fixo por local para a duração total do contrato, com os complementos detalhados separadamente. Exija que os licitantes incluam integração, suporte, atualizações de software e exportação de dados no encerramento, além de declarar quaisquer custos de hardware. A Purple apresenta cotações para três planos: Connect, Capture e Engage, com o SecurePass, Verify e Shield como complementos de segurança. Isso permite comparar as propostas item por item.

Nossa rede de WiFi para visitantes está no escopo do PCI DSS?

Não deveria estar, desde que esteja segmentada do seu ambiente de dados de portadores de cartão. O PCI DSS v4.0 permite reduzir o escopo por meio da segmentação, mas você precisa provar que ela funciona. O Requisito 11.4.5 exige testes de invasão dos controles de segmentação pelo menos a cada 12 meses. Especifique que o tráfego de visitantes nunca cruza com sistemas de pagamento e que nenhum dado de cartão é inserido no portal cativo.

Quem é o controlador de dados para os dados do WiFi para visitantes de acordo com a GDPR?

Geralmente, você é o controlador e o fornecedor de WiFi é o seu operador. O contrato, portanto, precisa de um acordo de processamento de dados do Artigo 28 cobrindo finalidade, segurança, suboperadores, exclusão e notificação de violações. Sua RFP também deve exigir registros de consentimento exportáveis e retenção configurável. Adicione ferramentas para responder a solicitações de acesso e exclusão dentro do prazo de um mês estabelecido pelo Artigo 12(3).

Precisamos de Passpoint ou OpenRoaming desde o primeiro dia?

Não, mas você deve exigir um roteiro precificado para ambos. Um portal cativo continua sendo a experiência adequada na primeira visita para capturar consentimento e dados próprios. O Passpoint e o OpenRoaming permitem que os visitantes recorrentes se conectem automaticamente, usando autenticação 802.1X criptografada sem página de login. A Purple oferece suporte ao OpenRoaming, para que você possa adicionar a conexão automática posteriormente dentro do mesmo contrato.

O DNS protetivo deve fazer parte do contrato de WiFi para visitantes?

Sim, especialmente para locais do setor público e frequentados por famílias. O DNS de proteção impede que os dispositivos acessem domínios vinculados a malware, phishing e servidores de comando e controle. Ele também pode aplicar filtragem por categoria em cada local. Torne isso um requisito essencial para conselhos, bibliotecas e ambientes de saúde. Exija uma página de bloqueio personalizada com a sua marca, uma política de DNS criptografada, relatórios mensais e retenção de logs alinhada ao seu cronograma da GDPR.

Quanta interrupção a troca de plataformas de WiFi para visitantes causa?

A troca é uma alteração de configuração em cada local, e não um projeto de hardware, quando a nova plataforma funciona como uma sobreposição. O Purple é integrado sobre a infraestrutura existente, portanto, seus APs, cabeamento e circuitos permanecem os mesmos. Execute um piloto de 30 dias em dois locais com hardwares diferentes e, em seguida, faça a implementação em etapas. Exporte os registros de consentimento da plataforma anterior antes da troca, para que nenhum opt-in legítimo seja perdido.

Por que não usar o portal cativo integrado à plataforma do nosso fornecedor de AP?

Porque um portal integrado vincula a integração, o consentimento e os dados a uma única marca de hardware. Propriedades com vários locais raramente permanecem em uma única plataforma após aquisições e ciclos de atualização. Uma plataforma independente mantém um único portal, um único registro de consentimento e uma única visualização de análise em todos os locais, independentemente do hardware. Isso protege seus dados e sua posição de negociação em cada atualização futura de hardware.