Requisitos para la RFP de WiFi para invitados: qué especificar en onboarding, seguridad y analítica

Una RFP de WiFi para invitados debe establecer requisitos medibles en cinco áreas. Incorporación: portal cautivo, captura de consentimiento y accesibilidad WCAG 2.2. Seguridad: IEEE 802.1X, RADIUS, Passpoint y WPA3. Hardware: compatibilidad explícita para Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist y Ubiquiti UniFi. Cumplimiento normativo: GDPR, PCI DSS v4.0 y DNS de protección. Analítica: datos propios exportables. Evalúe a los licitadores en función de las pruebas aportadas.

¿Qué debe especificar exactamente una RFP de WiFi para invitados?

Una RFP de WiFi para invitados convierte un resumen impreciso, como "WiFi gratis para invitados", en requisitos que un licitador puede cumplir o no. Define cómo se conectan los usuarios, cómo se protege el tráfico y en qué hardware debe ejecutarse la plataforma. También fija cómo se gestionan los datos personales y qué informes se reciben a cambio.

Las RFP deficientes suelen fallar del mismo modo. Enumeran características en lugar de normas, por lo que todos los licitadores responden "sí" y las propuestas parecen idénticas. La solución consiste en vincular cada apartado a una norma específica, las pruebas esperadas y una prueba piloto.

Para un patrimonio con múltiples instalaciones, la RFP también establece su modelo operativo para toda la duración del contrato. Un portal cautivo es la página web que ve un dispositivo antes de obtener acceso a internet. Puede gestionar un único portal cautivo y un único registro de consentimiento en todos los centros. La alternativa es una configuración diferente para cada proveedor de hardware. Resolver a posteriori un patrimonio fragmentado cuesta mucho más que especificar uno solo desde el principio.

Esta guía le ofrece la redacción de los requisitos, una matriz de puntuación y pruebas piloto. Utilícela como una plantilla de RFP de WiFi para invitados que puede adaptar para Hoteles, Comercio minorista, Sector sanitario, Trenes, estadios y recintos del sector público.

¿Qué necesita antes de redactar la RFP de WiFi para invitados?

Recopile cinco datos antes del primer borrador. Cada uno de ellos evitará una causa habitual de solicitudes de cambio tras la adjudicación.

• Un inventario de hardware por centro. Registre el proveedor del punto de acceso (AP), el modelo, la plataforma de gestión y el firmware en cada ubicación. Indique si cada ubicación utiliza un panel de control en la nube o un controlador local. Nuestra guía ¿Qué es un WLC (Wireless LAN Controller) y sigue siendo necesario? explica la diferencia.
• Una lista de centros por tipo. Agrupe las ubicaciones por sector vertical y tamaño, ya que la zona de distribución de un estadio y el vestíbulo de un hotel requieren procesos de incorporación distintos. Identifique a las personas a las que da servicio cada centro: invitados, compradores, pasajeros, aficionados, pacientes o visitantes.
• Un mapa de datos. Decida quién actúa como responsable del tratamiento de los datos, qué sistemas recibirán los datos de WiFi y durante cuánto tiempo se conservarán. Su delegado de protección de datos debe dar su visto bueno antes de enviar la RFP.
• Sus límites de pago. Enumere todos los sitios que acepten pagos con tarjeta. Indique si los dispositivos de pago comparten conmutadores o circuitos con el tráfico de invitados. Esto define su alcance de PCI DSS.
• Medidas de éxito. Acuerde las cifras sobre las que informará, como los inicios de sesión, la tasa de inclusión voluntaria, los visitantes recurrentes y las incidencias de soporte. De este modo, los licitadores podrán mostrar cómo sus informes generan cada una de ellas.

Involucre a los equipos de TI, seguridad, protección de datos, marketing y operaciones de los recintos desde el principio. El WiFi para invitados WiFi afecta a los cinco equipos. Un requisito redactado por un equipo suele bloquear a otro.

¿Cómo redactar los requisitos del RFP de WiFi para invitados WiFi, sección por sección?

Redacte cada requisito con «debe» o «debería», siguiendo la convención de la norma RFC 2119. Un «debe» es un filtro de apto o no apto. Un «debería» se puntúa. Pida a los licitadores que respondan a cada línea con pruebas: un documento, un certificado, un sitio de referencia o una demostración en directo.

Requisitos de incorporación y del portal cautivo

La incorporación es el momento en que los invitados juzgan su red y en el que se crean sus registros de consentimiento. Esta lista de comprobación de RFP para portales cautivos cubre los aspectos esenciales.

• Métodos de inicio de sesión. La plataforma debe admitir correo electrónico, inicio de sesión mediante redes sociales, SMS y códigos de acceso, configurables por recinto.
• Inclusiones voluntarias mediante decisión consciente. El consentimiento de marketing debe ser una opción independiente y no marcada, nunca vinculada a la aceptación de las condiciones. El artículo 7 del GDPR exige que el consentimiento sea demostrable y tan fácil de retirar como de otorgar.
• Accesibilidad. El portal cautivo debe cumplir la norma WCAG 2.2 nivel AA.
• Detección fiable del portal. La plataforma debería admitir la API del portal cautivo API (RFC 8908) y la opción de portal cautivo DHCP (RFC 8910). Ambas ayudan a que los dispositivos modernos encuentren la página de inicio de sesión sin bucles de redireccionamiento.
• Reconocimiento de visitantes recurrentes. iOS 14 e Android 10 en adelante utilizan direcciones MAC aleatorias de forma predeterminada. Pregunte a los licitadores cómo reconocen a un invitado recurrente sin depender de la dirección de hardware del dispositivo.
• Control centralizado. La sede principal debe gestionar la imagen de marca, las condiciones y la redacción del consentimiento de forma centralizada, con anulaciones locales para cada recinto.

Purple WiFi para invitados WiFi integra opciones de inclusión voluntaria mediante decisiones conscientes en el portal cautivo y las gestiona de forma centralizada en todo el patrimonio inmobiliario.

Requisitos de autenticación, RADIUS y Passpoint

RADIUS es el protocolo que utiliza un punto de acceso para preguntar a un servidor central si debe admitir un dispositivo. Se define en la norma RFC 2865. La contabilidad RADIUS, definida en la norma RFC 2866, registra el inicio, el fin y el uso de datos de la sesión. Para un patrimonio de múltiples recintos, especifique lo siguiente.

• RADIUS en la nube con redundancia. La autenticación debe seguir funcionando si falla un centro de datos. Solicite la arquitectura y 12 meses de disponibilidad medida.
• Transporte cifrado de RADIUS. Cuando RADIUS cruce la red pública de internet, exija RadSec (RADIUS sobre TLS, RFC 6614) o un túnel cifrado.
• Autorización dinámica. La plataforma debería enviar mensajes CoA (RFC 5176) para finalizar o cambiar una sesión sin forzar una reconexión.
• Segmentación. El tráfico de invitados debe alojarse en su propia VLAN, un segmento de red lógico aislado del personal y de los sistemas de pago. El aislamiento de clientes debe impedir que los dispositivos de los invitados se comuniquen entre sí.
• Cifrado en redes abiertas. Exija WPA3, incluido Enhanced Open (Opportunistic Wireless Encryption, RFC 8110). Cifra cada conexión sin necesidad de una contraseña compartida.
• Claves individuales según sea necesario. La iPSK (clave precompartida de identidad) proporciona a cada persona o dispositivo su propia contraseña de WiFi en una red compartida. Resulta ideal para huéspedes de larga estancia, expositores y personal de eventos. Purple ofrece esta función a través de SecurePass.

Passpoint, también denominado Hotspot 2.0, se basa en IEEE 802.11u. Permite que un dispositivo busque y se una a una red automáticamente, sin portal cautivo. La autenticación se realiza mediante IEEE 802.1X, el estándar para el control de acceso a redes basado en puertos, lo que garantiza que las credenciales permanezcan cifradas. OpenRoaming, gestionado por la Wireless Broadband Alliance, es una federación basada en Passpoint. Permite a los usuarios conectarse a las redes participantes mediante una identidad que ya posean.

Especifique Passpoint y OpenRoaming como requisitos recomendables ("should") en la primera fase, incluyendo un plan de trabajo valorado. Purple admite OpenRoaming, por lo que los invitados que regresen podrán conectarse automáticamente en sus instalaciones.

Si la RFP también incluye WiFi para empleados WiFi, exija la integración con Microsoft Entra ID, Okta y Google Workspace. De este modo, las incorporaciones, cambios de puesto y bajas se mantendrán sincronizados con el acceso a la red, sin necesidad de cambiar las contraseñas manualmente.

Compatibilidad con AP independiente del hardware

El criterio "Compatible con el hardware empresarial líder" no se puede evaluar. Especifique cada una de las plataformas que utilice actualmente o que pueda adoptar durante la vigencia del contrato. A continuación, exija las mismas cinco capacidades en cada una de ellas.

1. Soporte para portal cautivo externo.
2. Autenticación y contabilidad RADIUS.
3. Jardín vallado (walled garden): la lista de dominios permitidos antes del inicio de sesión necesaria para el portal y el acceso mediante redes sociales.
4. Soporte para CoA o una alternativa documentada para finalizar sesiones.
5. Una guía de integración publicada y al menos una referencia activa en dicha plataforma.

Proveedor	Plataforma de gestión a especificar en la RFP	Evidencia mínima a solicitar
Cisco Meraki	Panel de control de Meraki	Guía de integración, referencia activa, prueba piloto en su firmware
HPE Aruba	HPE Aruba Networking Central o Mobility Controller	Guía de integración, referencia activa, prueba piloto en su firmware
Ruckus	RUCKUS SmartZone o RUCKUS One	Guía de integración, referencia activa, prueba piloto en su firmware
Juniper Mist	Nube de Juniper Mist	Guía de integración, referencia activa, prueba piloto en su firmware
Ubiquiti UniFi	Aplicación de red UniFi	Guía de integración, referencia activa, prueba piloto en su firmware
Cambium	cnMaestro	Guía de integración, referencia activa, prueba piloto en su firmware
Extreme	ExtremeCloud IQ	Guía de integración, referencia activa, prueba piloto en su firmware
Fortinet	Controlador inalámbrico integrado FortiGate	Guía de integración, referencia activa, prueba piloto en su firmware

Solicite a cada licitador que especifique las versiones de firmware compatibles y, a continuación, realice pruebas con las suyas. Purple es independiente del hardware y funciona como una superposición en la nube en las ocho plataformas. No requiere una sustitución completa de la infraestructura. En Por qué su próxima actualización de WiFi no requiere hardware nuevo se aborda el aspecto comercial. Para entornos de Ruckus, consulte Ruckus SmartZone y RUCKUS One guest WiFi frente a plataformas externas de portal cautivo.

Cláusulas del GDPR que deben exigirse

El WiFi para invitados recopila datos personales a gran escala, por lo que el contrato debe incluir las siguientes cláusulas:

• Un acuerdo de tratamiento de datos que cumpla el artículo 28 del GDPR, y que abarque la finalidad, la seguridad, los encargados del tratamiento ulterior y la supresión.
• Registros de consentimiento que muestren la marca de tiempo, la versión del texto y el canal de cada inclusión voluntaria, exportables a petición.
• Conservación configurable con supresión automática, de conformidad con el principio de limitación del plazo de conservación del artículo 5, apartado 1, letra e).
• Herramientas para los interesados para buscar, exportar y suprimir los datos de una persona. Debe responder a las solicitudes en el plazo de un mes en virtud del artículo 12, apartado 3.
• Notificación de violaciones de la seguridad por parte del encargado del tratamiento sin dilación indebida, tal como exige el artículo 33, apartado 2. A continuación, dispone de 72 horas para notificarlo a la autoridad de control en virtud del artículo 33, apartado 1.
• Transferencias internacionales. El licitador debe declarar dónde se conservan los datos y el mecanismo de transferencia para cualquier tratamiento fuera del Reino Unido o del EEE.
• Pruebas de seguridad para el artículo 32, idealmente con certificación ISO 27001.

Purple cuenta con la certificación ISO 27001 y cumple con el GDPR, la CCPA y la Cyber Essentials.

Cláusulas de PCI DSS que deben exigirse

El WiFi para invitados nunca debe estar dentro de su entorno de datos de titulares de tarjetas (CDE). El CDE abarca los sistemas que almacenan, procesan o transmiten datos de tarjetas. PCI DSS v4.0 le permite reducir el alcance mediante la segmentación, pero debe demostrar que funciona.

• El licitador debe confirmar por escrito que el tráfico de invitados nunca atraviesa el CDE y documentar el diseño.
• El diseño debe ser compatible con su prueba de penetración de segmentación, exigida al menos cada 12 meses en virtud del requisito 11.4.5.
• No se pueden introducir datos de tarjetas en el portal cautivo. Cualquier acceso de pago debe utilizar un proveedor de pagos que cumpla con PCI DSS y aportar su atestación de cumplimiento (AoC).
• Sus pruebas trimestrales de detección de puntos de acceso inalámbricos no autorizados en virtud del requisito 11.2.1 siguen aplicando a las zonas para invitados.

Cláusulas de DNS protector que deben exigirse

El DNS protector impide que los dispositivos resuelvan dominios conocidos por alojar malware, suplantación de identidad (phishing) o servidores de comando y control. El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) ofrece un servicio de DNS protector a los organismos del sector público. Especifique lo siguiente:

• Fuentes de amenazas. El licitador debe indicar sus fuentes de inteligencia sobre amenazas y la frecuencia con la que se actualizan.
• Filtrado por categorías según el establecimiento, por ejemplo, bloqueando el contenido para adultos en bibliotecas y zonas familiares.
• Una página de bloqueo personalizada que informe al visitante de por qué se ha bloqueado un sitio web.
• Política de DNS cifrado. Especifique cómo maneja el servicio DNS sobre HTTPS (RFC 8484) y DNS sobre TLS (RFC 7858), los cuales pueden omitir el filtrado.
• Retención de registros alineada con su programación de GDPR. Los registros de DNS vinculados a una identidad con la sesión iniciada son datos personales.
• Informes mensuales de amenazas bloqueadas por ubicación.

Los complementos de seguridad de Purple son SecurePass, Verify y Shield. Solicite una demostración de cada uno con respecto a las cláusulas anteriores.

Requisitos de analítica e integración

La adquisición de WiFi para invitados empresarial a menudo subestima la analítica, aunque aquí es donde se ve el rendimiento de la inversión. Especifique lo siguiente:

• Métricas por ubicación y recinto: visitantes únicos, visitantes nuevos frente a recurrentes, tiempo de permanencia, frecuencia de visitas y horas punta.
• Paneles e informes programados, con acceso basado en roles para que los directores de las ubicaciones solo vean su propio sitio.
• Integraciones con sus plataformas de CRM y marketing, mediante API o conectores nativos. El estado del consentimiento debe acompañar a cada registro.
• Propiedad de los datos. Usted es el propietario de los datos propios. La exportación completa en CSV o JSON debe estar disponible en cualquier momento y al finalizar el servicio, sin coste adicional.

WiFi Analytics de Purple ofrece estas métricas por ubicación y se integra con plataformas de CRM y marketing.

Niveles de servicio y certificaciones

• Disponibilidad. Exija un SLA de tiempo de actividad mensual con créditos de servicio. La plataforma de Purple funciona con un tiempo de actividad del 99,999 %.
• Soporte. Especifique el horario, los tiempos de respuesta por gravedad y un contacto designado para escalaciones.
• Certificaciones. Exija ISO 27001. Los contratos del gobierno central del Reino Unido que gestionan datos personales requieren Cyber Essentials, según la Nota de Política de Contratación 09/14.
• Referencias de escala. Solicite referencias de su mismo volumen. Purple gestiona más de 80 000 ubicaciones activas en más de 90 países y procesó 440 millones de inicios de sesión en 2024 (datos propios de Purple).

Matriz de puntuación de requisitos

Área	Requisito	Prioridad	Evidencia a solicitar
Incorporación	Opción de inclusión en marketing independiente y no marcada	Imprescindible	Capturas de pantalla del portal y una muestra de exportación de consentimientos
Incorporación	Portal cautivo con WCAG 2.2 AA	Imprescindible	Informe de auditoría de accesibilidad independiente
Autenticación	RADIUS en la nube con conmutación por error	Imprescindible	Diagrama de arquitectura y 12 meses de datos de disponibilidad
Autenticación	RadSec o túnel RADIUS cifrado	Imprescindible	Documento de diseño
Autenticación	Passpoint y OpenRoaming	Deseable	Sitio de referencia activo
Cifrado	WPA3 y Enhanced Open	Deseable	Prueba piloto en sus AP
Hardware	Soporte designado para cada plataforma que ejecute	Imprescindible	Guía de integración y resultado del piloto
GDPR	APD del Artículo 28 y controles de retención	Imprescindible	APD firmado y demostración de la configuración de retención
PCI DSS	Tráfico de invitados fuera del CDE	Imprescindible	Diseño de segmentación y declaración de soporte de pruebas
DNS de protección	Filtrado de amenazas y categorías con página de bloqueo	Imprescindible para el sector público, deseable en el resto	Prueba de bloqueo en directo e informe mensual de muestra
Analítica	Exportación completa de datos al finalizar el contrato	Obligatorio	Cláusula contractual y archivo de muestra para exportación
Servicio	SLA de disponibilidad con créditos de servicio	Obligatorio	Anexo de SLA

¿Cómo verificar si un licitador puede cumplir?

Realice la evaluación en dos etapas: primero documental y después mediante una prueba piloto. Cualquier requisito obligatorio incumplido eliminará al licitador en la etapa documental. Pondere el resto de los requisitos deseables según sus prioridades. Un desglose habitual sería: seguridad y cumplimiento 30 %, incorporación 20 %, hardware 15 %, analítica 15 %, servicio 10 % y aspectos comerciales 10 %.

Lleve a cabo una prueba piloto de 30 días en dos o más establecimientos con diferentes plataformas de hardware. Pruebe cada uno de los siguientes puntos y registre si los supera o no.

• El portal cautivo se muestra a la primera en iOS, Android, Windows y macOS.
• Se reconoce a un visitante recurrente en su segunda visita.
• Una exportación de consentimientos muestra la marca de tiempo y la versión del texto informativo.
• Una solicitud de supresión elimina a la persona de la plataforma y de su CRM conectado.
• La autenticación continúa durante una conmutación por error simulada de RADIUS.
• Un mensaje de CoA finaliza la sesión sin permitir la reconexión.
• Se bloquea un dominio de prueba conocido, mostrando su página personalizada con su marca.
• Falla un intento de conexión desde el VLAN para invitados a la red de pagos.

Pruebe el rendimiento y la cobertura de forma independiente a la plataforma. El documento WiFi para internet: cómo funciona y qué comprobar incluye los conceptos básicos.

¿Cómo se traduce esto en la práctica?

Los tres escenarios descritos a continuación son supuestos representativos basados en patrones de contratación comunes. No constituyen casos de éxito de clientes reales.

Un grupo de 45 hoteles con dos plataformas de hardware distintas

Situación. El grupo utilizaba Cisco Meraki en 30 hoteles y HPE Aruba en 15 establecimientos adquiridos. Cada red contaba con su propio portal cautivo. En los 15 establecimientos adquiridos, el consentimiento de marketing se agrupaba conjuntamente con la aceptación de los términos y condiciones.

Acciones realizadas. En el pliego de condiciones se incluyeron ambas plataformas como requisitos obligatorios. Se exigió un portal único, un registro unificado de consentimientos y casillas de aceptación independientes. La prueba piloto se llevó a cabo en un hotel de cada plataforma.

Resultado. Dos de los cinco licitadores no superaron el filtro de hardware porque solo admitían una plataforma. La solución superpuesta adjudicataria permitió mantener los puntos de acceso existentes en los 15 establecimientos con Aruba. El consentimiento agrupado se eliminó en los 15 centros antes de la puesta en marcha.

Una cadena comercial de 120 tiendas dentro del alcance de PCI DSS

Situación. Los terminales de pago compartían conmutadores con los puntos de acceso para invitados en las tiendas más antiguas. Por lo tanto, el WiFi para invitados quedaba dentro del alcance de la evaluación PCI DSS de la cadena.

Acciones realizadas. El pliego de condiciones exigía un diseño de segmentación documentado y soporte por escrito para la prueba de penetración conforme a la norma 11.4.5. Asimismo, se prohibía la introducción de datos de tarjetas en el portal cautivo.

Resultado. La prueba de segmentación anual se superó con éxito en las 120 tiendas. El WiFi para invitados quedó fuera del alcance de PCI DSS, lo que redujo el volumen de sistemas que el auditor debía evaluar.

Un ayuntamiento con 25 bibliotecas y centros deportivos

Situación. El ayuntamiento necesitaba un servicio de WiFi público seguro para familias, Cyber Essentials y una página de inicio de sesión accesible.

Lo que se hizo. El DNS de protección era imprescindible, con filtrado por categorías para las zonas infantiles y una directiva de DNS cifrado. Los registros de DNS se conservaron durante 90 días, conforme al calendario de retención del ayuntamiento.

Resultado. Tres de los siete licitadores no superaron el filtro de las WCAG 2.2. En la prueba piloto, el filtrado de uno de los licitadores preseleccionados se eludió mediante DNS sobre HTTPS, lo que conllevó su eliminación del proceso.

¿Qué suele fallar en la contratación de WiFi para invitados y cómo solucionarlo?

Todos los licitadores responden "sí"

Causa: los requisitos describen funcionalidades en lugar de estándares. Solución: especifique la RFC, el estándar IEEE o el artículo del GDPR para cada punto y exija pruebas.

El portal cautivo no aparece

Causa: un jardín vallado (walled garden) incompleto o una detección deficiente del portal cautivo. Solución: exija la compatibilidad con RFC 8908 y RFC 8910, y pruebe cuatro sistemas operativos en el piloto.

Las cifras de visitantes parecen infladas

Causa: las direcciones MAC aleatorias hacen que un solo dispositivo parezca varios. Solución: exija el reconocimiento basado en la identidad de inicio de sesión y pida a los licitadores que expliquen cómo contabilizan los visitantes recurrentes.

El consentimiento no se sostiene legalmente

Causa: casillas de aceptación empaquetadas con los términos o ausencia de registro del texto mostrado. Solución: exija casillas de aceptación independientes y sin marcar, así como registros de consentimiento con control de versiones.

No se puede cambiar de proveedor

Causa: falta de una cláusula de exportación de datos. Solución: exija la exportación completa en formato CSV o JSON al finalizar el contrato, sin coste alguno.

El contrato obliga a cambiar de hardware

Causa: un proveedor vinculado a una única marca de puntos de acceso (AP). Solución: una cláusula de neutralidad de hardware que especifique cada plataforma que ejecute.

¿Cuánto cuesta y qué se obtiene a cambio?

Presupueste seis partidas de costes: licencias de software, hardware adicional, instalación, circuitos de internet, soporte y el tiempo de su propio equipo. La arquitectura que elija determinará la mayor parte de la diferencia.

Enfoque	Coste de hardware	Entorno de varios proveedores	Consentimiento y datos	Cambios en cada centro
Superposición en la nube sobre AP existentes (Purple)	Ninguno: se ejecuta en los AP existentes	Un único portal en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet	Registros de consentimiento centralizados y datos propios bajo su titularidad	Configuración de SSID y RADIUS en los AP existentes
Portal cautivo integrado del proveedor de AP	Ninguno en la plataforma actual	Un portal independiente para cada plataforma de hardware	Datos de visitantes y consentimiento almacenados por separado en cada plataforma	Configuración repetida en cada plataforma
Red gestionada con sustitución completa (rip-and-replace)	Nuevos AP y licencias en cada centro	Se impone un único proveedor de hardware en todo el entorno	Definido por las condiciones contractuales del proveedor	Instalación de nuevos AP en cada ubicación

Solicite a los licitadores que establezcan sus precios sobre una base única: un precio anual fijo por centro durante todo el periodo. Exija que los costes de incorporación, soporte, actualizaciones y salida se detallen por partidas. Purple ofrece presupuestos con base en tres planes (Connect, Capture y Engage), con SecurePass, Verify y Shield como complementos de seguridad.

El rendimiento procede de cuatro vías. Obtiene datos propios respaldados por un consentimiento legítimo. Observa las horas punta y el tiempo de permanencia para planificar la plantilla. Evita el gasto en hardware gracias a la superposición. Obtiene una única plataforma de soporte en lugar de varias. Purple ofrece esto desde 2012 en más de 80 000 ubicaciones activas.

Preguntas frecuentes

¿Puede ejecutarse una plataforma de WiFi para invitados en los puntos de acceso que ya poseemos?

Sí. Purple es independiente del hardware y funciona como una superposición en la nube en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Sus PA siguen gestionando la radio y el tráfico. Purple proporciona el portal cautivo, RADIUS en la nube, los registros de consentimiento y las analíticas. En su RFP, indique cada plataforma que ejecute y solicite una prueba piloto en su propio firmware antes de la adjudicación.

¿Cómo debemos pedir a los proveedores que fijen el precio del WiFi para invitados en una RFP?

Solicite un precio anual fijo por ubicación durante todo el periodo del contrato, con los complementos desglosados por separado. Exija a los licitadores que incluyan la incorporación, el soporte, las actualizaciones de software y la exportación de datos a la salida, además de especificar cualquier coste de hardware. Purple presupone en función de tres planes (Connect, Capture y Engage), con SecurePass, Verify y Shield como complementos de seguridad. Esto le permite comparar las ofertas línea por línea.

¿Nuestra red de WiFi para invitados está dentro del alcance de PCI DSS?

No debería estarlo, siempre que esté segmentada de su entorno de datos de titulares de tarjetas. PCI DSS v4.0 le permite reducir el alcance mediante la segmentación, pero debe demostrar que funciona. El requisito 11.4.5 exige pruebas de penetración de los controles de segmentación al menos cada 12 meses. Especifique que el tráfico de invitados nunca se cruza con los sistemas de pago y que no se introducen datos de tarjetas en el portal cautivo.

¿Quién es el responsable del tratamiento de los datos de WiFi para invitados según el GDPR?

Por lo general, usted es el responsable del tratamiento y el proveedor de WiFi es su encargado del tratamiento. Por lo tanto, el contrato necesita un acuerdo de encargado del tratamiento de datos en virtud del Artículo 28 que cubra la finalidad, la seguridad, los subencargados del tratamiento, la supresión y la notificación de brechas. Su RFP también debería exigir registros de consentimiento exportables y un periodo de conservación configurable. Añada herramientas para responder a las solicitudes de acceso y supresión dentro del plazo de un mes establecido por el Artículo 12(3).

¿Necesitamos Passpoint o OpenRoaming desde el primer día?

No, pero debería exigir un plan de actuación presupuestado para ambos. El portal cautivo sigue siendo la experiencia adecuada en la primera visita para captar el consentimiento y los datos propios. Passpoint y OpenRoaming permiten que los invitados que regresan se conecten automáticamente mediante autenticación cifrada 802.1X sin página de inicio de sesión. Purple es compatible con OpenRoaming, por lo que puede añadir la conexión automática más adelante dentro del mismo contrato.

¿Debería el DNS de protección formar parte del contrato de WiFi para invitados?

Sí, especialmente para el sector público y recintos familiares. El DNS de protección evita que los dispositivos accedan a dominios vinculados a software malicioso, suplantación de identidad (phishing) y servidores de comando y control. También permite aplicar un filtrado por categorías en cada recinto. Conviértalo en un requisito imprescindible para ayuntamientos, bibliotecas y centros sanitarios. Solicite una página de bloqueo personalizada con su marca, una directiva de DNS cifrada, informes mensuales y una retención de registros alineada con su calendario de GDPR.

¿Cuántas interrupciones causa el cambio de plataforma de WiFi para invitados?

El cambio es una modificación de la configuración en cada recinto, no un proyecto de hardware, cuando la nueva plataforma se ejecuta como una superposición. Purple se superpone a la infraestructura existente, por lo que sus puntos de acceso, cableado y circuitos se mantienen. Realice una prueba piloto de 30 días en dos recintos con hardware diferente y, a continuación, impleméntelo por fases. Exporte primero los registros de consentimiento de la plataforma saliente para no perder ninguna aceptación legal.

¿Por qué no utilizar el portal cautivo integrado en la plataforma de nuestro proveedor de puntos de acceso?

Porque un portal integrado vincula la incorporación, el consentimiento y los datos a una sola marca de hardware. Las propiedades con múltiples recintos raras veces se mantienen en una sola plataforma tras los procesos de adquisición y los ciclos de actualización. Una plataforma independiente mantiene un solo portal, un solo registro de consentimiento y una sola vista analítica en todos los centros, independientemente del hardware. Esto protege sus datos y su posición de negociación en cada futura actualización de hardware.