Requisitos de RFP para WiFi para invitados: qué especificar en incorporación, 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: soporte nominal para Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist y Ubiquiti UniFi. Cumplimiento: GDPR, PCI DSS v4.0 y DNS de protección. Analítica: datos propios exportables. Evalúe a los oferentes según las pruebas presentadas.

¿Qué necesita especificar realmente una RFP de WiFi para invitados?

Una RFP de WiFi para invitados transforma un informe impreciso, como "WiFi gratuito para invitados", en requisitos que un oferente puede cumplir o no. Define cómo se conectan las personas, cómo se protege el tráfico y en qué hardware debe ejecutarse la plataforma. También establece cómo se manejan los datos personales y qué informes recibirá usted.

Las RFP deficientes suelen fallar de la misma manera. Enumeran funciones en lugar de normas, por lo que todos los oferentes responden "sí" y las respuestas parecen idénticas. La solución consiste en adjuntar una norma definida, la evidencia que usted espera y una prueba piloto a cada línea.

Para una propiedad con múltiples recintos, la RFP también establece su modelo operativo durante la vigencia del contrato. Un portal cautivo es la página web que ve un dispositivo antes de acceder a internet. Usted puede operar un solo portal cautivo y un único registro de consentimiento en todos los sitios. La alternativa es una configuración diferente para cada proveedor de hardware. Desmantelar una propiedad fragmentada más adelante cuesta mucho más que especificar una sola desde ahora.

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

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

Reúna cinco elementos antes del primer borrador. Cada uno evita una causa común de solicitudes de cambio tras la adjudicación.

• Un inventario de hardware por recinto. Registre el proveedor del punto de acceso (AP), el modelo, la plataforma de gestión y el firmware en cada sitio. Tome nota de si cada sitio utiliza un panel en la nube o un controlador en las instalaciones. Nuestra guía ¿Qué es un WLC (Controlador de LAN inalámbrica) y aún necesita uno? explica la diferencia.
• Una lista de recintos por tipo. Agrupe los sitios por sector vertical y tamaño, ya que la zona común de un estadio y el vestíbulo de un hotel requieren procesos de incorporación distintos. Identifique a las personas a las que presta servicio cada recinto: invitados, compradores, pasajeros, aficionados, pacientes o visitantes.
• Un mapa de datos. Decida quién actúa como responsable del tratamiento de datos, qué sistemas recibirán los datos de WiFi y cuánto tiempo los conservará. Su oficial de protección de datos debe autorizar esto antes de enviar la RFP.
• Sus límites de pago. Enumere cada sitio que acepte pagos con tarjeta. Tenga en cuenta si los dispositivos de pago comparten conmutadores o circuitos con el tráfico de invitados. Esto define su alcance de PCI DSS.
• Métricas de éxito. Acuerde las cifras sobre las que informará, como los inicios de sesión, la tasa de aceptación (opt-in), los visitantes recurrentes y los tickets de soporte. Los licitadores podrán entonces mostrar cómo sus informes generan cada una de ellas.

Involucre a IT, seguridad, protección de datos, mercadotecnia y operaciones de las instalaciones desde el principio. El WiFi para invitados WiFi abarca a los cinco equipos. Un requisito redactado por un equipo a menudo bloquea a otro.

¿Cómo redactar los requisitos de una solicitud de propuesta (RFP) para WiFi para invitados WiFi, sección por sección?

Redacte cada requisito utilizando "debe" o "debería", siguiendo la convención de la RFC 2119. Un "debe" es un criterio de aprobación o reprobación. Un "debería" se puntúa. Solicite a los licitadores que respondan a cada línea con evidencia: un documento, un certificado, un sitio de referencia o una demostración en vivo.

Requisitos de incorporación y portal cautivo

La incorporación es el momento en que los invitados juzgan su red y donde se crean sus registros de consentimiento. Esta lista de verificación de RFP para portal cautivo 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 instalación.
• Aceptaciones de elección consciente. El consentimiento de mercadotecnia debe ser una opción independiente y no marcada, nunca vinculada a la aceptación de los términos. El artículo 7 del GDPR exige que el consentimiento se pueda demostrar y que sea tan fácil de retirar como de otorgar.
• Accesibilidad. El portal cautivo debe cumplir con las pautas WCAG 2.2 nivel AA.
• Detección confiable del portal. La plataforma debería admitir la API del portal cautivo API (RFC 8908) y la opción DHCP para portal cautivo (RFC 8910). Ambos ayudan a que los dispositivos modernos encuentren la página de inicio de sesión sin bucles de redireccionamiento.
• Reconocimiento de visitantes recurrentes. Las versiones de iOS 14 y Android 10 en adelante utilizan direcciones MAC aleatorias de manera 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 oficina central debe gestionar la imagen de marca, los términos y la redacción del consentimiento de forma centralizada, con anulaciones locales para cada instalación.

Purple WiFi para invitados WiFi integra aceptaciones de elección consciente en el portal cautivo y lo gestiona de forma centralizada en todas sus instalaciones.

Requisitos de autenticación, RADIUS y Passpoint

El protocolo RADIUS es el que utiliza un punto de acceso (AP) para consultar a un servidor central si debe admitir un dispositivo. Está definido en la norma RFC 2865. La contabilidad de RADIUS, definida en la norma RFC 2866, registra el inicio, la finalización y el uso de datos de la sesión. Para una red de múltiples instalaciones, 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 atraviese la red de internet pública, 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 evitar que los dispositivos de los invitados se comuniquen entre sí.
• Cifrado en redes abiertas. Exija WPA3, incluido Enhanced Open (Cifrado Inalámbrico Oportunista, RFC 8110). Este cifra cada conexión sin necesidad de una contraseña compartida.
• Claves individuales según sea necesario. iPSK (clave precompartida basada en la identidad) le otorga a cada persona o dispositivo su propia contraseña de WiFi dentro de una red compartida. Es ideal para invitados de larga estancia, expositores y personal de eventos. Purple proporciona esto a través de SecurePass.

Passpoint, también conocido como Hotspot 2.0, se basa en IEEE 802.11u. Permite que un dispositivo busque y se una a una red automáticamente, sin un 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 mantiene las credenciales cifradas. OpenRoaming, administrado por la Wireless Broadband Alliance, es una federación basada en Passpoint. Permite que las personas se unan a las redes participantes utilizando una identidad que ya poseen.

Especifique Passpoint y OpenRoaming como requisitos recomendados en la fase uno, acompañados de un plan de trabajo detallado con costos. Purple ofrece compatibilidad con OpenRoaming, de modo que los invitados habituales puedan conectarse automáticamente en sus instalaciones.

Si la RFP también incluye WiFi para empleados, solicite la integración con Microsoft Entra ID, Okta y Google Workspace. Esto mantiene sincronizadas las altas, cambios y bajas de personal con el acceso a la red, sin cambios manuales de contraseñas.

Compatibilidad con AP independiente del hardware

La frase "Compatible con el hardware empresarial líder" no se puede evaluar. Mencione cada una de las plataformas que utiliza o que podría adoptar durante la vigencia del contrato. Luego, exija las mismas cinco capacidades en cada una de ellas.

1. Soporte de portal cautivo externo.
2. Autenticación y contabilidad de RADIUS.
3. Jardín vallado: la lista de dominios permitidos previos al inicio de sesión necesarios para el portal y el inicio de sesión 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 esa plataforma.

Proveedor	Plataforma de gestión a mencionar 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 licitante que indique los rangos de firmware que admite y, luego, realice pruebas con la suya. Purple es independiente del hardware y funciona como una superposición en la nube en las ocho plataformas. No es necesario reemplazar la infraestructura existente. En Por qué su próxima actualización de WiFi no requiere nuevo hardware se explica el caso comercial. Para entornos Ruckus, consulte WiFi para invitados de Ruckus SmartZone y RUCKUS One frente a plataformas de Captive Portal externas.

Cláusulas del GDPR que se deben exigir

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

• Un acuerdo de procesamiento de datos que cumpla con el Artículo 28 del GDPR, que cubra el propósito, la seguridad, los subencargados del tratamiento y la eliminación.
• Registros de consentimiento que muestren la marca de tiempo, la versión del texto y el canal para cada aceptación, exportables a petición.
• Retención configurable con eliminación automática, de acuerdo con el principio de limitación del plazo de conservación del Artículo 5(1)(e).
• Herramientas para los titulares de los datos para buscar, exportar y eliminar los datos de una persona. Debe responder a las solicitudes en un plazo de un mes de conformidad con el Artículo 12(3).
• Notificación de brechas por parte del encargado del tratamiento sin dilación indebida, tal como lo exige el Artículo 33(2). A continuación, dispone de 72 horas para notificar al regulador en virtud del Artículo 33(1).
• Transferencias internacionales. El licitante debe indicar dónde se conservan los datos y el mecanismo de transferencia para cualquier procesamiento 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, UK GDPR, CCPA y Cyber Essentials.

Cláusulas de PCI-DSS que se deben exigir

El WiFi para invitados nunca debe estar dentro de su entorno de datos de cuentahabientes (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 licitante debe confirmar por escrito que el tráfico de invitados nunca atraviesa el CDE y documentar el diseño.
• El diseño debe respaldar su prueba de penetración de segmentación, requerida al menos cada 12 meses según el requisito 11.4.5.
• No se pueden ingresar datos de tarjetas en el Captive Portal. Todo acceso de pago debe utilizar un proveedor de pagos que cumpla con PCI-DSS, adjuntando su Atestación de Cumplimiento.
• Sus pruebas trimestrales para detectar puntos de acceso inalámbricos no autorizados según el requisito 11.2.1 siguen cubriendo las áreas de invitados.

Cláusulas de DNS de protección que se deben exigir

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

• Fuentes de amenazas. El licitante debe declarar sus fuentes de inteligencia sobre amenazas y la frecuencia con la que se actualizan.
• Filtrado por categorías por sede, por ejemplo, bloqueando contenido para adultos en bibliotecas y áreas familiares.
• Una página de bloqueo personalizada que informe al visitante por qué se bloqueó un sitio.
• Política de DNS encriptado. 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 cronograma de GDPR. Los registros de DNS vinculados a una identidad registrada se consideran datos personales.
• Reportes 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 a nivel empresarial a menudo subestima la analítica; sin embargo, aquí es donde se ve el retorno de inversión. Especifique lo siguiente:

• Métricas por ubicación y propiedad: visitantes únicos, visitantes nuevos frente a recurrentes, tiempo de permanencia, frecuencia de visitas y horas pico.
• Paneles de control y reportes programados, con acceso basado en roles para que los administradores de las ubicaciones vean únicamente 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 formato CSV o JSON debe estar disponible en cualquier momento y al finalizar el servicio, sin cargo adicional.

Purple WiFi Analytics reporta 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 99.999% de tiempo de actividad.
• Soporte. Especifique horarios, tiempos de respuesta según la gravedad y un contacto designado para escalaciones.
• Certificaciones. Exija ISO 27001. Los contratos del gobierno central del Reino Unido que manejan datos personales requieren Cyber Essentials, de conformidad con la Nota de Política de Adquisiciones 09/14.
• Referencias de escala. Solicite referencias acordes a su tamaño. Purple opera 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 evaluación de requisitos

Área	Requisito	Prioridad	Evidencia a solicitar
Incorporación	Opción de suscripción a marketing independiente y desmarcada	Imprescindible	Capturas de pantalla del portal y muestra de exportación de consentimientos
Incorporación	Portal cautivo con certificación WCAG 2.2 AA	Imprescindible	Informe de auditoría independiente de accesibilidad
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 encriptado	Imprescindible	Documento de diseño
Autenticación	Passpoint y OpenRoaming	Deseable	Sitio de referencia en vivo
Encriptación	WPA3 y Enhanced Open	Deseable	Prueba piloto en sus AP
Hardware	Soporte designado para cada plataforma que utilice	Imprescindible	Guía de integración y resultado de la prueba piloto
GDPR	DPA según el Artículo 28 y controles de retención	Imprescindible	DPA 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 los demás casos	Prueba de bloqueo en vivo y reporte mensual de muestra
Analítica	Exportación completa de datos al finalizar	Obligatorio	Cláusula contractual y archivo de muestra de exportación
Servicio	SLA de tiempo de actividad con créditos de servicio	Obligatorio	Anexo de SLA

¿Cómo verificar que un proveedor puede cumplir?

Evalúe en dos etapas: documental y luego prueba piloto. Cualquier requisito "obligatorio" no cumplido elimina al proveedor en la etapa documental. Pondere las líneas "deseables" restantes para que coincidan con sus prioridades. Una distribución típica es: seguridad y cumplimiento 30%, incorporación 20%, hardware 15%, analítica 15%, servicio 10% y aspectos comerciales 10%.

Ejecute una prueba piloto de 30 días en dos o más ubicaciones con diferentes plataformas de hardware. Pruebe cada uno de los siguientes puntos y registre si se aprueba o no.

• El portal cautivo aparece a la primera en iOS, Android, Windows y macOS.
• Se reconoce a un invitado recurrente en su segunda visita.
• Una exportación de consentimiento muestra la marca de tiempo y la versión del texto.
• Una solicitud de eliminación borra a la persona de la plataforma y de su CRM conectado.
• La autenticación continúa durante un fallo simulado de RADIUS.
• Un mensaje CoA finaliza una sesión sin reconexión.
• Un dominio de prueba conocido se bloquea, mostrando su página personalizada con su marca.
• Un intento de conexión desde el VLAN para invitados a la red de pagos falla.

Pruebe el rendimiento y la cobertura por separado de la plataforma. WiFi para internet: cómo funciona y qué verificar cubre los aspectos básicos.

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

Los tres escenarios siguientes son ejemplos ilustrativos basados en patrones comunes de adquisición. No son estudios de caso de clientes.

Un grupo de 45 hoteles en dos plataformas de hardware

Situación. El grupo ejecutaba Cisco Meraki en 30 hoteles y HPE Aruba en 15 propiedades adquiridas. Cada propiedad tenía su propio portal cautivo. En los 15 sitios adquiridos, el consentimiento de marketing se incluyó en paquete con la aceptación de los términos.

Qué se hizo. La RFP definió ambas plataformas como requisitos "obligatorios". Requirió un solo portal, un solo registro de consentimiento y opciones de inclusión voluntaria independientes. La prueba piloto incluyó un hotel en cada plataforma.

Resultado. Dos de cinco proveedores no pasaron el filtro de hardware porque solo admitían una plataforma. La solución superpuesta ganadora mantuvo los 15 sitios Aruba en sus AP existentes. El consentimiento en paquete se eliminó en los 15 sitios antes del lanzamiento.

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

Situación. Los terminales de pago compartían switches con los AP de invitados en las tiendas más antiguas. Por lo tanto, el WiFi para invitados estaba dentro de la evaluación PCI DSS de la cadena.

Qué se hizo. La RFP exigió un diseño de segmentación documentado y soporte por escrito para la prueba de penetración 11.4.5. También prohibió el ingreso de datos de tarjetas en el portal cautivo.

Resultado. La prueba anual de segmentación se aprobó en las 120 tiendas. El WiFi para invitados quedó fuera del alcance de PCI DSS, lo que redujo los sistemas que el evaluador tenía que revisar.

Un ayuntamiento con 25 bibliotecas y centros deportivos

Situación. El ayuntamiento necesitaba WiFi para invitados 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 un requisito indispensable, con filtrado por categorías para áreas infantiles y una política de DNS cifrado. Los registros de DNS se conservaron durante 90 días, en cumplimiento con el programa de retención del ayuntamiento.

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

¿Qué sale mal en la adquisición de WiFi para invitados y cómo solucionarlo?

Todos los licitantes responden "sí"

Causa: los requisitos describen funciones, no estándares. Solución: especifique la RFC, el estándar IEEE o el artículo de GDPR para cada línea y exija evidencia.

El portal cautivo no aparece

Causa: un jardín amurallado incompleto o una detección deficiente del portal cautivo. Solución: exija compatibilidad con las RFC 8908 y RFC 8910, y pruebe cuatro sistemas operativos en la prueba 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 solicite a los licitantes que expliquen cómo contabilizan a los visitantes recurrentes.

El consentimiento no es válido legalmente

Causa: casillas de verificación vinculadas a los términos o falta de registro del texto mostrado. Solución: exija casillas de verificación independientes y desmarcadas, así como registros de consentimiento con control de versiones.

No puede cancelar la relación comercial

Causa: ausencia 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 costo alguno.

El contrato fuerza la compra de hardware nuevo

Causa: un proveedor vinculado a una sola marca de puntos de acceso. Solución: una cláusula de neutralidad de hardware que especifique cada plataforma que usted utilice.

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

Considere presupuesto para seis conceptos de costo: 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	Costo de hardware	Red de múltiples proveedores	Consentimiento y datos	Cambio en cada establecimiento
Superposición en la nube en AP existentes (Purple)	Ninguno: se ejecuta en los AP existentes	Un solo portal en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet	Registros centrales de consentimiento y datos propios que le pertenecen	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 consentimiento y de visitantes guardados por separado en cada plataforma	Configuración repetida en cada plataforma
Reemplazo total de la red administrada	Nuevos AP y licencias en cada establecimiento	Se impone un solo proveedor de hardware en toda la red	Definido por los términos del contrato del proveedor	Instalación de nuevos AP en cada sitio

Solicite a los licitantes una cotización bajo una sola base: un precio fijo anual por establecimiento durante la totalidad del contrato. Exija que se desglose el costo de incorporación, soporte, actualizaciones y salida. Purple cotiza sobre la base de tres planes: Connect, Capture y Engage, con SecurePass, Verify y Shield como complementos de seguridad.

El retorno proviene de cuatro aspectos. Usted obtiene datos propios respaldados por el consentimiento legal. Observa las horas pico y el tiempo de permanencia para planificar el personal. Evita gastos en hardware a través de la superposición. Obtiene una sola plataforma con soporte en lugar de varias. Purple ha cumplido con 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 puntos de acceso siguen administrando la radio y el tráfico. Purple proporciona el portal cautivo, la RADIUS en la nube, los registros de consentimiento y la analítica. En su RFP, mencione cada plataforma que utilice y solicite una prueba piloto en su propio firmware antes de la adjudicación.

¿Cómo debemos pedir a los proveedores que coticen el WiFi para invitados en un RFP?

Solicite un precio anual fijo por ubicación durante todo el plazo 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 al finalizar, así como también que indiquen cualquier costo de hardware. Purple cotiza sobre la base de tres planes, Connect, Capture y Engage, con SecurePass, Verify y Shield como complementos de seguridad. Esto le permite comparar ofertas línea por línea.

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

No debería estarlo, siempre y cuando esté segmentada de su entorno de datos de cuentahabientes. 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 cruce con los sistemas de pago y que no se ingrese ningún dato de tarjeta en el portal cautivo.

¿Quién es el responsable del tratamiento de los datos del 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 tratamiento de datos según el Artículo 28 que cubra el propósito, la seguridad, los subencargados del tratamiento, la eliminación y la notificación de vulneraciones. Su RFP también debe exigir registros de consentimiento exportables y una retención configurable. Agregue herramientas para responder a las solicitudes de acceso y eliminació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 debe solicitar una hoja de ruta con costos detallados para ambos. Un portal cautivo sigue siendo la experiencia adecuada en la primera visita para capturar el consentimiento y los datos propios. Passpoint y OpenRoaming permiten que los invitados que regresan se conecten automáticamente, utilizando la autenticación cifrada de 802.1X sin página de inicio de sesión. Purple es compatible con OpenRoaming, por lo que puede agregar la conexión automática más adelante dentro del mismo contrato.

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

Sí, especialmente para recintos de sectores públicos y familiares. El DNS de protección evita que los dispositivos accedan a dominios vinculados con malware, phishing y servidores de comando y control. También puede aplicar filtrado por categorías según el recinto. Conviértalo en algo "imprescindible" para ayuntamientos, bibliotecas y centros de atención médica. Solicite una página de bloqueo personalizada con su marca, una directiva de DNS cifrada, informes mensuales y retención de registros alineada con su calendario de GDPR.

¿Qué nivel de interrupción causa cambiar de plataforma de WiFi para invitados?WiFi

El cambio representa una modificación de configuración en cada recinto, no un proyecto de hardware, cuando la nueva plataforma funciona como una superposición. Purple se superpone a la infraestructura existente, por lo que sus AP, cableado y circuitos permanecen en su lugar. Ejecute una prueba piloto de 30 días en dos recintos con diferente hardware y, a continuación, realice el despliegue por fases. Exporte primero los registros de consentimiento de la plataforma saliente para no perder ninguna opción de inclusión voluntaria conforme a la ley.

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

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 rara vez se mantienen en una sola plataforma tras los procesos de adquisición y ciclos de actualización. Una plataforma independiente mantiene un solo portal, un solo registro de consentimiento y una sola vista analítica en cada sitio, independientemente del hardware. Eso protege sus datos y su posición de negociación en cada futura actualización de hardware.