Qué puede revisar un DPD en la web de un cliente sin ayuda de informática

Si trabaja como delegado de protección de datos (DPD) o como consultor de RGPD, conoce el momento. El registro de actividades de tratamiento está en orden, las cláusulas informativas están redactadas, los contratos de encargo están firmados. Entonces llega a la web, y en las notas de la revisión pone «pendiente de verificar por informática». El cliente no tiene informático y la agencia que hizo la web no contesta.

Sin embargo, la web suele ser el único sistema de su cliente que acepta datos personales de cualquier persona en internet: un formulario de contacto, una suscripción al boletín, una reserva de cita. Buena parte de ella puede evaluarla usted, sin acceso de administrador y sin formación técnica. Aquí explicamos cómo y cómo dejarlo por escrito.

Qué exige el artículo 32 a una web

El artículo 32 del RGPD obliga al responsable y al encargado del tratamiento a aplicar «medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo». Entre sus ejemplos están el cifrado, la confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas, la restauración rápida de los datos tras un incidente y «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento».

En una web pública eso se traduce en unas pocas preguntas concretas. ¿Los datos de los formularios viajan cifrados hasta el servidor? ¿El software está actualizado? ¿Podría un desconocido descargar archivos con datos personales? ¿La web cede datos de los visitantes a terceros sin base jurídica? ¿Y alguien comprueba todo esto con regularidad y lo deja registrado?

La última pregunta enlaza con la responsabilidad proactiva. Según el artículo 5, apartado 2, el responsable del tratamiento responde del cumplimiento de los principios del apartado 1, entre ellos la integridad y la confidencialidad, y debe ser «capaz de demostrarlo». El artículo 39, apartado 1, letra b), incluye entre las funciones del DPD supervisar el cumplimiento del RGPD, incluidas las auditorías correspondientes. Una revisión fechada de la web encaja ahí sin problema. Para la parte que corresponde al responsable, incluida la notificación de violaciones en 72 horas, consulte El RGPD y su web.

Lo que puede comprobar usted en 20 minutos

Todo lo que sigue lo puede hacer cualquier visitante, así que no necesita ningún acceso. Si quiere lanzar herramientas de análisis automático contra la web, pida antes permiso al cliente. En cada paso haga una captura de pantalla en la que se vean la dirección del sitio y la fecha.

1. El candado y el certificado. Haga clic en el icono junto a la dirección del sitio y abra los detalles del certificado. Anote quién lo emitió y cuándo caduca. Después escriba la dirección a mano con http:// en lugar de https://. La web debería pasar sola a la versión https. Si se queda en http, los datos de los formularios pueden viajar sin cifrar. El comprobador gratuito de certificados SSL (en inglés) cubre el resto, incluidas las versiones antiguas del protocolo.

2. La política de privacidad. ¿Hay un enlace en el pie de todas las páginas y junto a cada formulario? ¿Funciona o lleva a un error 404? ¿La política identifica al responsable que realmente gestiona la web y menciona las herramientas que se ven en ella? Una política redactada hace años se aleja fácilmente de una web que desde entonces ha incorporado un chat o un píxel publicitario.

3. Formularios. Abra cada página que tenga un formulario y compruebe el candado. Un formulario incrustado desde otro servicio, como un sistema de reservas o una herramienta de boletines, es un destinatario más de los datos y requiere un contrato de encargo con el cliente. Compruebe que junto a él hay una breve cláusula informativa y que el formulario no pide más de lo que su finalidad necesita. Un campo para el número de documento de identidad en un formulario de contacto es motivo de conversación. En Su formulario de contacto es una puerta de entrada se explica qué más puede fallar en los formularios.

4. Cookies antes del consentimiento. Abra la web en una ventana privada y no toque el banner de cookies. Pulse F12, vaya a la pestaña Aplicación (Application) en Chrome o Edge, o Almacenamiento en Firefox, y abra la lista de cookies. Si ya hay cookies analíticas o publicitarias antes de que haga clic en nada, por ejemplo _ga de Google Analytics o _fbp del píxel de Meta, el seguimiento empieza sin consentimiento. Después haga clic en «Rechazar», recargue la página y compruebe si desaparecen. La regla del consentimiento previo procede del artículo 5, apartado 3, de la Directiva sobre la privacidad y las comunicaciones electrónicas (2002/58/CE), tal como la ha incorporado cada país a su legislación, y no del propio RGPD. Los datos personales que recogen esas herramientas sí son materia del RGPD. Para una primera pasada rápida sin F12, la comprobación de cookies antes del consentimiento (en inglés) muestra las cookies que fija el servidor y los rastreadores presentes en el código de la página. Las cookies que los scripts escriben después solo aparecen en el navegador.

5. El correo del dominio. Introduzca el dominio del cliente en la comprobación de SPF, DKIM y DMARC (en inglés). Sin DMARC, cualquiera puede enviar correos que parecen venir de su cliente, también a los propios clientes de su cliente, para pedirles datos personales o un pago. Es un riesgo de violación de datos que empieza fuera de la web pero usa el mismo dominio.

6. Versiones de software visibles. Pulse Ctrl+U para ver el código fuente de la página y busque (Ctrl+F) generator. A menudo encontrará algo como WordPress 6.x. Compare el número con la versión actual en wordpress.org. Un número de versión visible no es una vulnerabilidad en sí, pero una versión antigua sugiere que tampoco nadie actualiza los plugins. Si la etiqueta no aparece, eso no demuestra nada, porque se puede ocultar.

Lo que no se ve desde fuera

Una revisión desde el navegador tiene límites, y sus notas deben recogerlos igual que recogen los hallazgos:

• las copias de seguridad: si existen, dónde se guardan y si alguien ha restaurado alguna vez el sitio a partir de una,
• las cuentas de administración: quién tiene acceso de administrador y si usa el inicio de sesión en dos pasos,
• las versiones de los plugins que no aparecen en el código de la página, y quién las mantiene al día,
• qué pasa con un envío del formulario después de enviarse: si se queda en la base de datos, durante cuánto tiempo y a qué bandeja llega,
• la configuración del servidor, los registros y la protección de la base de datos,
• dónde está el alojamiento y si los datos salen del EEE.

Conviértalas en preguntas para el cliente o para su desarrollador web, y anote quién respondió y cuándo. La falta de respuesta también es un resultado y también va a las notas.

Cómo dejar constancia de la revisión

Una nota de revisión debe sostenerse si dentro de un año alguien pregunta cómo lo sabía. Use siempre el mismo formato:

1. Fecha y hora, dirección del sitio, quién revisó y con qué navegador.
2. La lista de puntos revisados, cada uno marcado como correcto, a corregir o no comprobable.
3. Capturas de pantalla de cada punto a corregir.
4. Quién recibió los resultados, cuándo y en qué forma.
5. El plazo de corrección acordado con el responsable y la fecha de la revisión de seguimiento.

Un registro así sirve a las dos partes. El cliente tiene prueba de la verificación regular que pide el artículo 32, apartado 1, letra d). Usted tiene prueba de que supervisó y transmitió sus recomendaciones. La corrección en sí corresponde al responsable y a quien le hace la web.

Repita la revisión al menos una vez al año y después de cualquier cambio importante, como una nueva agencia web o una nueva tienda online. Dos informes fechados muestran si se siguieron sus recomendaciones.

Cuando tiene muchos clientes

Con una docena de clientes o más, revisar a mano cada web empieza a comerse días enteros. La parte exterior se puede automatizar con ShieldWave. Revisa cada sitio tal como lo ve cualquiera en internet, incluidos archivos expuestos, cabeceras de seguridad y vulnerabilidades conocidas en las versiones de software, y le entrega un informe PDF fechado con correspondencia con el RGPD. La parte técnica va tal cual al desarrollador del cliente, sin necesidad de traducirla. El plan Pro cuesta 12 USD al mes para un máximo de 25 sitios web. No certifica el cumplimiento del RGPD ni mira dentro del panel de administración, así que las preguntas del apartado anterior siguen siendo cosa suya.