El caso de cumplimiento para un WiFi sin contraseñas: HIPAA, PCI, ISO 27001

El WiFi sin contraseña, es decir, el estándar 802.1X con EAP-TLS basado en certificados, no es un requisito obligatorio de HIPAA, PCI DSS 4.0 o ISO 27001:2022. Las tres normativas exigen una identificación única, un cifrado sólido, una revocación inmediata y registros de auditoría. Una contraseña compartida presenta dificultades en cada uno de estos puntos. Los certificados por dispositivo cumplen con cada expectativa por diseño y generan los registros que un auditor analiza.

¿Qué significa realmente el cumplimiento de WiFi sin contraseña?

El WiFi sin contraseña sustituye una contraseña de red compartida por una credencial única para cada dispositivo o persona. En redes empresariales, esto suele significar el estándar IEEE 802.1X para el control de acceso a redes basado en puertos. El estándar 802.1X delega la decisión a un servidor RADIUS. RADIUS es el protocolo que utilizan los puntos de acceso para preguntar a un servidor de autenticación si un dispositivo puede unirse a la red.

El método más seguro es EAP-TLS (Protocolo de autenticación extensible con seguridad de la capa de transporte). Tanto el dispositivo como el servidor presentan certificados digitales. No hay contraseñas que puedan ser objeto de phishing, que se puedan compartir o que se puedan escribir en un pizarrón de la sala de personal. Cada sesión deriva sus propias claves de cifrado bajo WPA2-Enterprise o WPA3-Enterprise.

Es necesario señalar dos métodos relacionados:

• PEAP (EAP protegido) con un nombre de cuenta y contraseña utiliza 802.1X, pero no es un sistema sin contraseña. Hereda cada una de las debilidades de la contraseña que lo respalda.
• iPSK (clave previamente compartida de identidad) asigna a cada dispositivo su propia clave en un solo nombre de red. Es un puente práctico para los equipos que no pueden almacenar un certificado.

El "cumplimiento de WiFi sin contraseña" es la forma abreviada de responder a una pregunta. ¿La forma en que su personal y sus dispositivos se unen a la red cumple con los controles de acceso, cifrado y registro bajo los cuales se le audita? Ninguno de los tres marcos de referencia en esta guía nombra explícitamente a EAP-TLS. Sin embargo, los tres describen resultados que una contraseña compartida hace que sean difíciles de demostrar.

¿Por qué una contraseña de WiFi compartida falla en una auditoría?

Una clave previamente compartida (PSK) es un único secreto conocido por todos en la red. Ese solo hecho genera cuatro problemas de auditoría:

• Falta de atribución. Cada dispositivo se autentica con el mismo secreto. Los registros muestran una dirección MAC, no a una persona, y las direcciones MAC se pueden suplantar.
• La revocación implica rotación. Eliminar a un empleado que se retira de la empresa significa cambiar la clave en cada uno de los dispositivos. El requisito 2.3.2 de PCI DSS hace que esta rotación sea obligatoria en las redes conectadas a datos de tarjetas.
• Amplio radio de impacto. Una sola clave filtrada expone a toda la red, y a menudo a cada sitio que la comparte.
• Evidencia insuficiente. No es posible demostrar a un auditor quién conocía la clave, cuándo la obtuvo o que el personal que ya no trabaja ahí ya no la tiene.

El acceso basado en certificados revierte cada uno de estos puntos. Cada conexión conlleva una identidad única. Revocar un certificado o deshabilitar una cuenta elimina un dispositivo o a una persona. Nadie conoce una clave, por lo que nadie se va con ella.

¿Cómo cumple el WiFi basado en certificados con PCI DSS 4.0?

PCI-DSS v4.0 se convirtió en la única versión activa cuando v3.2.1 se retiró el 31 de marzo de 2024. Sus requisitos con fecha futura se volvieron obligatorios el 31 de marzo de 2025. La revisión limitada v4.0.1, publicada en junio de 2024, utiliza los mismos números de requisitos referenciados a continuación.

¿El WiFi sin contraseña cumple con PCI?

No por sí solo. El cumplimiento de PCI pertenece al entorno evaluado, no a un producto. El WiFi sin contraseña sí satisface o simplifica los requisitos que las contraseñas compartidas hacen difíciles de cumplir:

• 1.3.3 requiere controles de seguridad de red entre cada red inalámbrica y el entorno de datos de titulares de tarjetas (CDE). El CDE es el conjunto de sistemas que almacenan, procesan o transmiten datos de tarjetas. El tráfico inalámbrico hacia el CDE debe denegarse por defecto. El acceso basado en identidad ubica los dispositivos autorizados en una VLAN (LAN virtual) específica y deniega todo lo demás.
• 2.3.1 y 2.3.2 requieren que cambie las claves inalámbricas predeterminadas del proveedor. También debe cambiar las claves de cifrado inalámbrico cada vez que alguien que las conocía deje la empresa. Con EAP-TLS ninguna persona conoce una clave, por lo que el activador por salida de personal nunca se dispara.
• 4.2.1.2 requiere criptografía sólida para la autenticación y transmisión en redes inalámbricas que transportan datos de tarjetas o que están conectadas al CDE. PCI-DSS ha prohibido WEP desde 2010. La autenticación mutua de certificados con WPA2-Enterprise o WPA3-Enterprise cumple con este requisito.
• 8.2.2 restringe las cuentas compartidas y genéricas a casos excepcionales con justificación documentada. Una contraseña de red compartida por 200 empleados es difícil de justificar.
• 8.2.5 requiere que el acceso del personal desvinculado se revoque de inmediato. Deshabilitar una cuenta en su proveedor de identidad logra esto.
• 10.2.1 y 10.5.1 requieren registros de auditoría, conservados durante 12 meses con los tres meses más recientes disponibles de inmediato. Los registros RADIUS de 802.1X atribuyen cada conexión a un certificado o cuenta.

El WiFi sin contraseña no cubre el Requisito 11.2.1. Ese requisito le pide que realice pruebas para detectar puntos de acceso autorizados y no autorizados al menos una vez cada tres meses. Sigue siendo su responsabilidad, como lo explica la sección de límites.

¿HIPAA requiere WiFi basado en certificados?

No. La Regla de Seguridad de HIPAA (45 CFR Parte 164, Subpart C) es tecnológicamente neutra y no nombra ningún protocolo inalámbrico. Establece estándares y especificaciones de implementación, algunos "requeridos" y otros "direccionables". Direccionable significa que usted implementa la especificación cuando sea razonable y apropiado. De lo contrario, documenta el porqué y adopta una alternativa equivalente.

El WiFi basado en certificados se alinea perfectamente con las salvaguardas técnicas en §164.312:

• Identificación única, §164.312(a)(2)(i), requerido. Cada dispositivo y persona en la red tiene una identidad distinta.
• Cifrado y descifrado, §164.312(a)(2)(iv), direccionable. Las claves por sesión protegen la ePHI (información de salud electrónica protegida) que se transmite de forma inalámbrica.
• Controles de auditoría, §164.312(b), requerido. Los registros RADIUS registran qué identidad se conectó, desde qué punto de acceso y cuándo.
• Autenticación de persona o entidad, §164.312(d), obligatoria. Un certificado demuestra que el dispositivo es el que afirma ser. Vincularlo a una cuenta de proveedor de identidad extiende esa prueba a la persona.
• Seguridad de la transmisión, §164.312(e)(1). Los controles de integridad y el cifrado son especificaciones abordables bajo este estándar.

Las salvaguardas administrativas también importan. El análisis de riesgos en §164.308(a)(1)(ii)(A) es donde se registra por qué sus controles inalámbricos son razonables. Los procedimientos de rescisión en §164.308(a)(3)(ii)(C) son más fáciles de evidenciar cuando la desactivación de una sola cuenta elimina el acceso a la red.

Observe la dirección del cambio. En enero de 2025, el Departamento de Salud y Servicios Humanos de los EE. UU. (HHS) publicó una propuesta de norma. Esta eliminaría la mayor parte de la distinción entre obligatorio y abordable. También haría obligatorios el cifrado y la autenticación multifactor, con excepciones limitadas. Es una propuesta, no una norma final. El acceso basado en certificados ya se encuentra del lado correcto de la misma.

¿Qué dice ISO 27001 sobre las redes inalámbricas?

ISO/IEC 27001:2022 no tiene un control llamado "inalámbrico". El Anexo A enumera 93 controles en cuatro temas, y varios se aplican directamente a cómo el personal se une a una red. ISO/IEC 27002:2022, la guía de implementación, aborda las redes inalámbricas bajo el control 8.22. Señala que los perímetros inalámbricos están mal definidos. Para entornos sensibles, sugiere tratar el acceso inalámbrico como una conexión externa hasta que pase por una puerta de enlace.

Los controles que un auditor evaluará:

• 5.15 Control de acceso y 5.18 Derechos de acceso. Reglas sobre quién puede unirse, y cómo se aprovisiona y elimina ese acceso.
• 5.16 Gestión de identidades y 5.17 Información de autenticación. Identidades y secretos gestionados a lo largo de su ciclo de vida. Una contraseña compartida es información de autenticación que no se puede asignar a una sola persona.
• 8.5 Autenticación segura. Tecnología de autenticación adecuada a la sensibilidad del acceso.
• 8.15 Registro y 8.16 Monitoreo de actividades. Registros que graban eventos y evidencia de que alguien los revisa.
• 8.20 Seguridad de las redes, 8.21 Seguridad de los servicios de red y 8.22 Segregación de redes.
• 8.24 Uso de criptografía.
• 5.19 y 5.23. Relaciones con proveedores y servicios en la nube, que se aplican si su autenticación se ejecuta como un servicio en la nube.

Las organizaciones certificadas en ISO/IEC 27001:2013 tenían hasta el 31 de octubre de 2025 para realizar la transición. Si su Declaración de Aplicabilidad todavía utiliza la numeración de 2013, como A.9 o A.13, actualícela.

Cómo se relacionan los tres marcos con WiFi sin contraseñas

Control	Marco	Lo que solicita	Contraseña compartida (PSK)	Basado en certificados (EAP-TLS)
1.3.3	PCI DSS 4.0	Denegación por defecto entre la red inalámbrica y el CDE	Cada dispositivo con la clave aterriza en un segmento	VLAN por identidad, denegada por defecto
2.3.2	PCI DSS 4.0	Cambiar las claves inalámbricas cuando se vaya cualquier persona que las conozca	Rotar con cada baja, en cada dispositivo	Ninguna persona posee una clave; se revoca un solo certificado
8.2.2	PCI-DSS 4.0	Cuentas compartidas solo por excepción documentada	Compartido por diseño	Una credencial por dispositivo o persona
10.5.1	PCI-DSS 4.0	12 meses de logs, tres meses disponibles de inmediato	Los logs solo muestran direcciones MAC	Los logs nombran el certificado o la cuenta
§164.312(a)(2)(i)	HIPAA	Identificación única (requerida)	No se cumple con la credencial de red	Cumplido por diseño
§164.312(b)	HIPAA	Controles de auditoría (requeridos)	Atribución débil	Cada sesión es atribuible
§164.312(e)(1)	HIPAA	Seguridad de transmisión	Encriptado, pero la clave es conocida por todo el personal	Encriptado con claves que ninguna persona conoce
5.17	ISO 27001:2022	Información de autenticación asignada y administrada	No se puede asignar a una sola persona	Emitido, renovado y revocado por identidad
5.18	ISO 27001:2022	Derechos de acceso aprovisionados y eliminados	La eliminación requiere un cambio de clave en toda la red	La eliminación sigue al proveedor de identidad
8.22	ISO 27001:2022	Segregación de redes	Un segmento por clave	Segmento por rol o tipo de dispositivo

¿Qué evidencia solicitará un auditor?

Los auditores evalúan el diseño, la configuración y el funcionamiento. El diseño son sus diagramas. La configuración son sus exportaciones. El funcionamiento son sus logs y muestras. Prepare el paquete antes del trabajo de campo, no durante el mismo.

Elemento de evidencia	Qué demuestra	PCI-DSS 4.0	HIPAA	ISO 27001:2022
Diagramas de red y de flujo de datos que muestran los límites del personal, invitados y CDE	Diseño de segmentación	1.2.3, 1.2.4	§164.308(a)(1)	8.20, 8.22
Reglas de firewall o ACL entre las VLAN de WiFi del personal y el CDE	Denegación por defecto en la práctica	1.3.3	§164.312(e)(1)	8.22
Exportación de configuración de SSID que muestra el modo Enterprise y EAP-TLS	Autenticación y encriptación fuertes	4.2.1.2	§164.312(a)(2)(iv)	8.5, 8.24
Política de certificados: CA emisora, periodo de validez, renovación, revocación	Ciclo de vida de la información de autenticación	4.2.1.2	§164.312(d)	5.17
Muestra de bajas: tiempo de desactivación de la cuenta frente a la última autenticación de red	Revocación oportuna	8.2.5	§164.308(a)(3)(ii)(C)	5.18
Logs de RADIUS con configuraciones de retención	Atribución y retención	10.2.1, 10.5.1	§164.312(b)	8.15
Inventario de puntos de acceso y resultados de escaneo trimestral de rogue APs	Control de puntos de acceso autorizados y no autorizados	11.2.1, 11.2.2	§164.308(a)(1)	8.16
Certificados y contratos de proveedores	Aseguramiento de terceros	12.8	§164.308(b) donde el proveedor maneja ePHI	5.19, 5.23

¿Cómo se prueban los controles de WiFi a un auditor?

Realice usted mismo la prueba de bajas primero. Es la prueba que una contraseña compartida no puede superar de manera limpia.

1. Exporte su lista de bajas de RR. HH. para el periodo de auditoría.
2. Seleccione una muestra, por ejemplo, de 10 a 25 bajas en diferentes sitios.
3. Para cada una, obtenga la hora de desactivación de la cuenta de su proveedor de identidad.
4. Obtenga la última autenticación de red exitosa para esa identidad a partir de los registros de RADIUS.
5. Cualquier autenticación posterior a la hora de deshabilitación constituye un hallazgo. Corrija la causa antes de que el auditor la encuentre.

En una red PSK, el paso cuatro no genera ningún resultado útil. Ningún registro vincula una conexión con la persona que se marcha, por lo que no se puede probar que haya dejado de conectarse.

¿Dónde encaja el WiFi sin contraseña junto con lo que ya tiene en funcionamiento?

No necesita nuevos puntos de acceso. 802.1X es una función estándar de los puntos de acceso empresariales. Purple es independiente del hardware y se ejecuta como una capa en la nube sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet.

Purple Staff WiFi utiliza redes basadas en la identidad (Identity-Based Networks). El acceso a la red sigue a su proveedor de identidad: Microsoft Entra ID, Okta o Google Workspace. Los nuevos empleados obtienen acceso cuando se crea su cuenta. Los empleados que cambian de puesto cambian de segmento de red cuando cambia su rol. Los empleados que se marchan pierden el acceso cuando se deshabilita la cuenta. Ese flujo de altas, cambios y bajas (JML, por sus siglas en inglés) es lo que genera pruebas claras para PCI DSS 8.2.5, HIPAA §164.308(a)(3)(ii)(C) y el control 5.18 de ISO 27001.

Su red de invitados permanece separada. PCI DSS 1.3.3 se aplica tanto a ella como a las redes del personal: se debe denegar el tráfico de invitados hacia el CDE. Los planes de Guest WiFi de Purple cumplen con GDPR y CCPA para los datos de los visitantes, tal como se establece en Connect vs Capture.

Para su archivo de proveedores, Purple cuenta con las certificaciones ISO 27001 y Cyber Essentials, y cumple con GDPR y CCPA. Los propios datos de la plataforma de Purple muestran un tiempo de actividad del 99.999% en más de 80,000 establecimientos activos. Su auditor los tratará como garantías del proveedor, no como prueba de sus propios controles.

¿Cómo se ve el cumplimiento de WiFi sin contraseña en la práctica?

Los tres escenarios siguientes son ejemplos prácticos. Cada uno establece sus suposiciones, para que pueda volver a realizar los cálculos para su propio patrimonio.

Un hotel de 200 habitaciones: eliminando la rotación de claves PCI

Situación. Un hotel de 200 habitaciones opera con 140 empleados en una sola red PSK. Las computadoras de recepción y las tabletas del restaurante en esa red acceden al sistema de pago, lo que lo sitúa dentro del alcance de PCI. Supongamos una rotación anual de personal del 30%, es decir, 42 personas que se marchan al año.

Qué se hizo. La red del personal se migró a 802.1X con EAP-TLS, vinculada al proveedor de identidad del grupo hotelero. Los dispositivos de pago se trasladaron a una VLAN dedicada con reglas de denegación por defecto desde cualquier otra red. La red de invitados se aisló de ambas.

Resultado. Las rotaciones de claves del requisito 2.3.2 disminuyen de 42 al año (cada una afectando a todos los dispositivos del personal) a cero. Cada persona que se marcha se elimina deshabilitando una sola cuenta. La muestra de bajas ahora tiene un registro contra el cual realizar la comparación. Los operadores de Hotels con personal de temporada experimentan la mayor reducción, ya que la rotación impulsa la necesidad de rotar claves.

Una cadena minorista de 40 tiendas: reduciendo el radio de impacto

Situación. Una cadena de 40 tiendas utiliza una sola PSK en todas las tiendas para los escáneres de inventario portátiles y las laptops de oficina. Los gerentes de las tiendas conocen la clave. Un exgerente la publica en línea. Qué se hizo. Las laptops administradas se migraron a EAP-TLS con certificados emitidos a través de la gestión de dispositivos. Los escáneres que no podían almacenar certificados se migraron a iPSK, con una clave por dispositivo, en una VLAN restringida. El inventario de puntos de acceso de cada tienda se documentó bajo el Requisito 11.2.2.

Resultado. La exposición ante una credencial filtrada se reduce de 40 tiendas a un solo dispositivo. Revocar ese dispositivo requiere una sola acción y mantiene los demás escáneres conectados. La cadena ahora puede mostrar a un evaluador un inventario por dispositivo en lugar de un único secreto compartido. El mismo patrón se adapta a cualquier propiedad de Retail con una combinación de dispositivos administrados y sin interfaz de usuario.

Un departamento de salud del condado: atribución de HIPAA en 12 clínicas

Situación. El departamento de salud de un condado de EE. UU. opera 12 clínicas. Los médicos utilizan tabletas compartidas para acceder al expediente clínico electrónico. Cada clínica tiene su propia contraseña de red, lo que resulta en 12 credenciales compartidas y ninguna atribución en los registros de red.

Qué se hizo. Las tabletas recibieron certificados de dispositivo. Los médicos inician sesión con su cuenta de proveedor de identidad, por lo que cada sesión vincula un dispositivo a una persona. Los registros de RADIUS alimentan el sistema de gestión de registros del departamento. La retención se estableció conforme al período de documentación de seis años de la sección §164.316(b)(2), donde el departamento clasifica los registros como documentación.

Resultado. Las credenciales de red compartidas se reducen de 12 a cero. El análisis de riesgos puede registrar la especificación de cifrado como implementada en lugar de documentar una alternativa. Los controles de auditoría bajo la sección §164.312(b) ahora muestran qué persona, en qué dispositivo, se unió a qué red de clínica y cuándo. Los equipos del sector público de Healthcare que responden tanto a HIPAA como a auditorías estatales pueden reutilizar el mismo paquete de evidencias. Los dispositivos de la tripulación en los Trains siguen el mismo modelo, con una identidad por tableta en cada vagón y depósito.

¿Cuáles son las limitaciones que debe conocer?

• No es un certificado de cumplimiento. El WiFi sin contraseñas satisface controles específicos. El alcance, el análisis de riesgos y el resto de cada marco de trabajo siguen siendo su responsabilidad.
• Los puntos de acceso no autorizados aún requieren pruebas. PCI DSS 11.2.1 exige pruebas trimestrales para detectar puntos de acceso autorizados y no autorizados. El acceso basado en certificados no detecta un dispositivo no autorizado conectado a un switch de la tienda.
• Los certificados expiran. Necesita una autoridad de certificación, un método de inscripción y un proceso de renovación. Una renovación omitida desconecta a todos los dispositivos cuyo certificado comparta esa fecha de vencimiento.
• No todos los dispositivos pueden almacenar un certificado. Las impresoras, los escáneres y algunos equipos clínicos no pueden hacerlo. Utilice iPSK o una red segmentada, y documente la excepción.
• PEAP no es un atajo. PEAP con contraseñas mantiene el riesgo de las contraseñas. Si los dispositivos no validan el certificado del servidor, un punto de acceso falso puede capturar las credenciales.
• Los registros solo ayudan si se retienen y revisan. Establezca la retención en 12 meses para PCI DSS. Evidencie una frecuencia de revisión para el control 8.16 de ISO 27001.

¿Qué debe hacer a continuación?

1. Clasifique cada nombre de red. Marque cuáles tocan el CDE, la ePHI o ninguno. Esto decide qué marco de trabajo se aplica a cada uno.
2. Ejecute la prueba de baja de empleados ahora. Si no puede completarla, habrá encontrado su primer riesgo de auditoría.
3. Elija una credencial por clase de dispositivo. EAP-TLS para laptops, teléfonos y tablets administrados. iPSK para dispositivos sin pantalla.
4. Actualice su documentación de control. Mapee el cambio en su Declaración de Aplicabilidad, análisis de riesgos de HIPAA o documento de alcance de PCI DSS.
5. Haga un piloto en un sitio. Pruebe la inscripción de certificados, la asignación de VLAN y la revocación de bajas antes de implementarlo en toda la propiedad.
6. Construya el paquete de evidencias. Utilice la tabla de evidencias anterior como su lista de verificación, tres meses antes del trabajo de campo.

Preguntas frecuentes

¿El WiFi sin contraseña cumple con PCI?

El WiFi sin contraseña no cumple con PCI por sí solo, porque PCI DSS evalúa su entorno en lugar de un producto. Sí satisface los Requisitos 2.3.2, 4.2.1.2, 8.2.2 y 8.2.5 de manera más limpia que una contraseña compartida, y sus registros de RADIUS respaldan el Requisito 10. Aún necesita controles de denegación por defecto entre las redes inalámbricas y el entorno de datos de tarjetahabientes según el 1.3.3, además de pruebas trimestrales de puntos de acceso no autorizados según el 11.2.1.

¿La ley HIPAA requiere WiFi basado en certificados?

No, HIPAA no menciona ninguna tecnología inalámbrica. La Regla de Seguridad requiere identificación única, controles de auditoría y autenticación de personas o entidades, y trata el cifrado como direccionable. El WiFi basado en certificados cumple con todo esto por diseño, lo que hace que su análisis de riesgos sea más fácil de defender. Una propuesta de regla de la HHS de enero de 2025 haría obligatorios el cifrado y la autenticación multifactor con excepciones limitadas. Es una propuesta, no una regla final.

¿Qué dice la norma ISO 27001 sobre las redes inalámbricas?

ISO/IEC 27001:2022 no tiene un control específico para redes inalámbricas. Los auditores prueban las redes inalámbricas frente a los controles del Anexo A del 5.15 al 5.18 para acceso e identidad, 8.5 para autenticación segura, 8.15 para registro de eventos, y del 8.20 al 8.22 para seguridad y segregación de redes. La guía de ISO/IEC 27002:2022 bajo el apartado 8.22 sugiere tratar el acceso inalámbrico en entornos sensibles como una conexión externa hasta que pase por una puerta de enlace.

¿Cómo demuestro los controles de WiFi a un auditor?

Usted demuestra los controles de WiFi con configuración, registros de eventos y una prueba de baja de empleados. Presente diagramas de red que muestren los límites de la red inalámbrica y del CDE, exportaciones de SSID que muestren la autenticación Enterprise, su política de certificados, 12 meses de registros de RADIUS y resultados trimestrales de escaneos de puntos de acceso no autorizados. Luego, ejecute una muestra de bajas de empleados, comparando la hora de desactivación de la cuenta de cada empleado dado de baja con su última autenticación de red exitosa. Cualquier autenticación posterior a la desactivación es un hallazgo.

¿El WiFi para personal de Purple funciona con nuestros puntos de acceso existentes?

Sí, Purple es agnóstico del hardware y se ejecuta como una capa en la nube sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Usted conserva sus puntos de acceso y switches. Purple conecta el acceso a la red con Microsoft Entra ID, Okta o Google Workspace, por lo que abandonar el uso de una contraseña compartida no requiere de un costoso proyecto de reemplazo de hardware.

¿Qué pasa con los dispositivos que no admiten un certificado?

Utilice iPSK o una red segmentada independiente para ellos. iPSK le asigna a cada dispositivo su propia clave en el mismo nombre de red, por lo que revocar un dispositivo mantiene al resto conectado. Coloque los equipos sin interfaz de usuario, como impresoras y escáneres, en una VLAN restringida. Documente la justificación comercial en su análisis de riesgos o Declaración de aplicabilidad, y revise cada excepción en cada ciclo de auditoría.

¿La certificación ISO 27001 de Purple nos hace cumplir con las normativas?

No, la certificación de un proveedor no se transfiere a usted. Las credenciales ISO 27001, Cyber Essentials, GDPR y CCPA de Purple sirven como evidencia para su evaluación de proveedores según los controles 5.19 y 5.23 de ISO 27001 y el Requisito 12.8 de PCI DSS. Su propio alcance, análisis de riesgos, configuración y registros aún deben cumplir con cada marco regulatorio, y su auditor los evaluará directamente.