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

La WiFi sin contraseña, lo que significa 802.1X con EAP-TLS basado en certificados, no es un mandato obligatorio de HIPAA, PCI DSS 4.0 o ISO 27001:2022. Las tres normas exigen una identificación única, un cifrado fuerte, una revocación inmediata y registros de auditoría. Una contraseña compartida tiene dificultades en todos estos aspectos. Los certificados por dispositivo cumplen con cada expectativa por diseño y producen los registros que un auditor muestrea.

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

La WiFi sin contraseña sustituye la contraseña de red compartida por una credencial única para cada dispositivo o persona. En las redes empresariales, esto suele traducirse en IEEE 802.1X, el estándar para el control de acceso a la red basado en puertos. El estándar 802.1X cede 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.

El método más robusto 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 ninguna contraseña que pescar con phishing, compartir o escribir en la pizarra de la sala del 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 una contraseña es 802.1X, pero no es sin contraseña. Hereda cada una de las debilidades de la contraseña que tiene detrás.
• iPSK (clave precompartida de identidad) otorga a cada dispositivo su propia clave en un único nombre de red. Es un puente práctico para aquellos equipos que no pueden contener un certificado.

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

¿Por qué una contraseña de WiFi compartida no supera una auditoría?

Una clave precompartida (PSK) es un único secreto conocido por todos los usuarios de la red. Ese simple hecho genera cuatro problemas de auditoría.

• Sin atribución. Todos los dispositivos se autentican con el mismo secreto. Los registros muestran una dirección MAC, no una persona, y las direcciones MAC se pueden suplantar.
• La revocación implica rotación. Eliminar a un empleado que se marcha significa cambiar la clave en cada dispositivo. El requisito 2.3.2 de PCI DSS hace que esa 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 todos los sitios que la comparten.
• Evidencia escasa. No puede demostrar a un auditor quién conocía la clave, cuándo la aprendió o que el antiguo personal ya no la tiene en su poder.

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

¿Cómo cumple la WiFi basada en certificados con PCI DSS 4.0?

PCI-DSS v4.0 se convirtió en la única versión activa cuando la v3.2.1 se retiró el 31 de marzo de 2024. Sus requisitos con fecha futura pasaron a ser 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 requisito que se indican a continuación.

¿Cumple el WiFi sin contraseña con PCI-DSS?

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

• 1.3.3 exige 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 la identidad coloca a los dispositivos autorizados en una VLAN (LAN virtual) específica y deniega todo lo demás.
• 2.3.1 y 2.3.2 le exigen que cambie las claves inalámbricas predeterminadas del proveedor. También debe cambiar las claves de cifrado inalámbrico cada vez que se vaya alguien que las conocía. Con EAP-TLS ninguna persona conoce la clave, por lo que el desencadenante de salida de empleados nunca se activa.
• 4.2.1.2 exige criptografía fuerte para la autenticación y transmisión en redes inalámbricas que transporten datos de tarjetas o estén conectadas al CDE. PCI-DSS prohíbe WEP desde 2010. La autenticación mutua mediante certificados con WPA2 o WPA3 en su versión 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 exige que el acceso del personal que cause baja se revoque de inmediato. Deshabilitar una cuenta en su proveedor de identidad se encarga de ello.
• 10.2.1 y 10.5.1 exigen registros de auditoría, conservados durante 12 meses, con los tres meses más recientes disponibles de inmediato. Los registros de 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 compruebe si hay puntos de acceso autorizados y no autorizados al menos una vez cada tres meses. Sigue siendo tarea suya, tal como explica la sección de límites.

¿Exige HIPAA un WiFi basado en certificados?

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

El WiFi basado en certificados se alinea perfectamente con las salvaguardas técnicas de la §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 protegida electrónica) en tránsito por el aire.
• Controles de auditoría, §164.312(b), requerido. Los registros de RADIUS registran qué identidad se conectó, desde qué punto de acceso y cuándo.
• Autenticación de personas o entidades, §164.312(d), requerido. Un certificado demuestra que el dispositivo es el que dice ser. Vincularlo a una cuenta de proveedor de identidad amplía esa demostración a la persona.
• Seguridad de transmisión, §164.312(e)(1). Los controles de integridad y el cifrado son especificaciones abordables bajo esta norma.

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 tendencia del sector. En enero de 2025, el Departamento de Salud y Servicios Humanos de los EE. UU. (HHS) publicó una propuesta de norma. Eliminaría la mayor parte de la distinción entre requerido y abordable. También haría obligatorios el cifrado y la autenticación multifactor, con excepciones limitadas. Es una propuesta, no una norma definitiva. El acceso basado en certificados ya se sitúa en el lado correcto de la misma.

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

ISO/IEC 27001:2022 no tiene ningún control llamado "inalámbrico". El Anexo A enumera 93 controles en cuatro temas, y varios se aplican directamente a cómo el personal se conecta 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 una pasarela.

Los controles que un auditor pondrá a prueba:

• 5.15 Control de acceso y 5.18 Derechos de acceso. Normas sobre quién puede conectarse 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 confidencialidad del acceso.
• 8.15 Registro y 8.16 Actividades de supervisión. Registros que graban eventos y pruebas 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 asocian los tres marcos al WiFi sin contraseñas

Control	Marco de referencia	Qué 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, denegación por defecto
2.3.2	PCI DSS 4.0	Cambiar las claves inalámbricas cuando se marcha cualquiera que las conociera	Rotar con cada baja de personal, en cada dispositivo	Ninguna persona posee una clave; se revoca un único certificado
8.2.2	PCI DSS 4.0	Cuentas compartidas solo por excepción documentada	Compartidas 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 muestran solo direcciones MAC	Los logs nombran el certificado o la cuenta
§164.312(a)(2)(i)	HIPAA	Identificación única (obligatorio)	No cumplido por la credencial de red	Cumplido por diseño
§164.312(b)	HIPAA	Controles de auditoría (obligatorio)	Atribución débil	Cada sesión es atribuible
§164.312(e)(1)	HIPAA	Seguridad de la transmisión	Encriptado, pero la clave la conoce todo el personal	Encriptado con claves que nadie conoce
5.17	ISO 27001:2022	Asignación y gestión de la información de autenticación	No se puede asignar a una sola persona	Emitida, renovada y revocada por identidad
5.18	ISO 27001:2022	Suministro y retirada de derechos de acceso	La retirada requiere un cambio de clave en toda la red	La retirada 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é pruebas solicitará un auditor?

Los auditores prueban 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 prueba	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 el 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 la configuración del SSID que muestra el modo Enterprise y EAP-TLS	Autenticación y encriptación sólidas	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: hora 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 ajustes 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 escaneos trimestrales de dispositivos rogue	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	Garantía de terceros	12.8	§164.308(b) donde el proveedor gestiona ePHI	5.19, 5.23

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

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

1. Exporte su lista de bajas de RR. HH. correspondiente al periodo de auditoría.
2. Seleccione una muestra, por ejemplo de 10 a 25 bajas en diferentes sedes.
3. Para cada una, extraiga la hora de desactivación de la cuenta de su proveedor de identidad.
4. Obtenga del registro de RADIUS la última autenticación de red que se haya completado con éxito para esa identidad.
5. Cualquier autenticación posterior a la hora de inhabilitación se considera un hallazgo. Corrija la causa antes de que la detecte el auditor.

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

¿Cómo encaja el WiFi sin contraseñas con lo que ya tiene implementado?

No necesita nuevos puntos de acceso. 802.1X es una función estándar en los puntos de acceso empresariales. Purple es independiente del hardware y funciona 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. El acceso a la red sigue a su proveedor de identidad: Microsoft Entra ID, Okta o Google Workspace. Las nuevas incorporaciones obtienen acceso en cuanto se crea su cuenta. Los empleados que cambian de puesto pasan a otro segmento de red si cambian sus funciones. Y las personas que causan baja pierden el acceso en cuanto se inhabilita la cuenta. Ese flujo de altas, cambios y bajas (JML) 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 independiente. La norma PCI DSS 1.3.3 se aplica a ella tanto 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 el GDPR y la CCPA para los datos de los visitantes, tal como se establece en Connect vs Capture.

Para su registro de proveedores, Purple cuenta con las certificaciones ISO 27001 y Cyber Essentials, y cumple con el GDPR y la CCPA. Los datos de la propia plataforma de Purple muestran un tiempo de actividad del 99.999 % en más de 80 000 ubicaciones activas. Su auditor tratará esto como una garantía del proveedor, no como prueba de sus propios controles.

¿Cómo es en la práctica el cumplimiento de un WiFi sin contraseñas?

Los tres escenarios siguientes son ejemplos prácticos. En cada uno se detallan las premisas iniciales para que pueda recalcular las cifras según su propia situación.

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

Situación. Un hotel de 200 habitaciones tiene a 140 empleados en una misma red PSK. Los ordenadores de recepción y las tabletas del restaurante conectados a esa red acceden al sistema de pago, lo que la sitúa dentro del alcance de PCI. Se asume una rotación de personal anual del 30 %, es decir, 42 bajas al año.

Qué se hizo. La red del personal se migró a 802.1X con EAP-TLS, vinculada al proveedor de identidad de la cadena hotelera. 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 pasan de ser 42 al año, afectando cada una de ellas a todos los dispositivos de la plantilla, a cero. Para dar de baja a un empleado basta con desactivar una cuenta. El muestreo de bajas dispone ahora de un registro con el que contrastar. Los operadores de Hotels con personal de temporada experimentan la mayor reducción, ya que la rotación de personal es lo que obliga a cambiar las claves.

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

Situación. Una cadena de 40 tiendas utiliza una única PSK en todos los establecimientos para los lectores de inventario portátiles y los ordenadores portátiles de administración. Los responsables de las tiendas conocen la clave. Un antiguo responsable la publica en internet.

Qué se hizo. Los portátiles gestionados pasaron a EAP-TLS con certificados emitidos a través de la gestión de dispositivos. Los escáneres que no podían admitir certificados pasaron a iPSK, con una clave por dispositivo, en una VLAN restringida. El inventario de puntos de acceso de cada tienda se documentó según 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 conectados los demás escáneres. 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 sector de Retail con una mezcla de dispositivos gestionados y desatendidos.

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

Situación. Un departamento de salud de un condado de EE. UU. gestiona 12 clínicas. Los profesionales sanitarios utilizan tabletas compartidas para acceder al registro médico electrónico. Cada clínica tiene su propia contraseña de red, lo que genera 12 credenciales compartidas y ninguna atribución en los registros de red.

Qué se hizo. Las tabletas recibieron certificados de dispositivo. Los profesionales sanitarios inician sesión con su cuenta de proveedor de identidad, de modo que cada sesión vincula un dispositivo a una persona. Los registros RADIUS alimentan la gestión de registros del departamento. La retención se estableció de acuerdo con el periodo 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 de 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 de Healthcare del sector público que deben responder tanto ante HIPAA como ante la auditoría estatal pueden reutilizar el mismo paquete de pruebas. 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 los límites 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 de su responsabilidad.
• Los puntos de acceso no autorizados aún deben probarse. 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 al conmutador de una tienda.
• Los certificados caducan. Necesita una autoridad de certificación, un método de inscripción y un proceso de renovación. Una renovación omitida desconecta todos los dispositivos cuyo certificado comparta esa fecha de caducidad.
• No todos los dispositivos pueden albergar 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 conservan y se revisan. Establezca la retención en 12 meses para PCI DSS. Acredite una cadencia de revisión para el control 8.16 de ISO 27001.

¿Qué debería hacer a continuación?

1. Clasifique cada nombre de red. Marque cuáles tocan el CDE, la ePHI o ninguno de los dos. Eso decide qué marco de cumplimiento se aplica a cada uno.
2. Ejecute la prueba de bajas de personal ahora. Si no puede completarla, habrá encontrado su primer riesgo de auditoría.
3. Elija una credencial por clase de dispositivo. EAP-TLS para portátiles, teléfonos y tabletas gestionados. iPSK para dispositivos sin pantalla.
4. Actualice su documentación de controles. Refleje el cambio en su Declaración de aplicabilidad, análisis de riesgos de HIPAA o documento de alcance de PCI DSS.
5. Realice un piloto en un centro. Demuestre el registro de certificados, la asignación de VLAN y la revocación de bajas antes de implementarlo en todo el parque.
6. Prepare el paquete de pruebas. Utilice la tabla de pruebas anterior como 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í cumple con los Requisitos 2.3.2, 4.2.1.2, 8.2.2 y 8.2.5 de forma más clara que una contraseña compartida, y sus registros 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 titulares de tarjetas bajo el punto 1.3.3, además de pruebas trimestrales de puntos de acceso no autorizados según el punto 11.2.1.

¿Exige la norma HIPAA el WiFi basado en certificados?

No, la norma HIPAA no nombra ninguna tecnología inalámbrica. La Regla de seguridad exige una 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 norma del HHS de enero de 2025 haría obligatorios el cifrado y la autenticación multifactor con excepciones limitadas. Es una propuesta, no una norma final.

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

La norma ISO/IEC 27001:2022 no tiene ningún control específico para redes inalámbricas. Los auditores evalúan la red inalámbrica frente a los controles del Anexo A 5.15 a 5.18 para acceso e identidad, 8.5 para autenticación segura, 8.15 para registro de actividad y 8.20 a 8.22 para seguridad y segregación de redes. La guía 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 pasarela de red.

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

Los controles de WiFi se demuestran con la configuración, los registros de actividad y una prueba de bajas de personal. Presente diagramas de red que muestren los límites de la red inalámbrica y el CDE, exportaciones de SSID que muestren autenticación Enterprise, su política de certificados, 12 meses de registros RADIUS y los resultados trimestrales de análisis de puntos de acceso no autorizados. A continuación, realice una muestra de bajas, comparando la hora de desactivación de la cuenta de cada empleado saliente con su última autenticación de red exitosa. Cualquier autenticación posterior a la desactivación se considera un hallazgo.

¿Funciona Purple Staff WiFi con nuestros puntos de acceso actuales?

Sí, Purple es independiente del hardware y se ejecuta como una superposición en la nube en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Mantendrá sus puntos de acceso y conmutación. Purple conecta el acceso a la red con Microsoft Entra ID, Okta o Google Workspace, por lo que abandonar una contraseña compartida no requiere un proyecto de sustitución integral de hardware.

¿Qué ocurre con los dispositivos que no pueden albergar un certificado?

Utilice iPSK o una red segmentada independiente para ellos. iPSK proporciona a cada dispositivo su propia clave en el mismo nombre de red, por lo que revocar un dispositivo deja 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 la normativa?

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 la evaluación de sus 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, y su auditor los evaluará directamente.