El RGPD y su sitio web: de qué responde usted como propietario

Un formulario de contacto, una suscripción al boletín, una reserva de cita, una cuenta de cliente en su tienda. Todos recogen un nombre, una dirección de correo y a veces un teléfono. Según el RGPD, eso son datos personales, y su empresa es la responsable del tratamiento.

Muchos propietarios dan por hecho que, como el sitio lo hizo una agencia y el servidor lo gestiona una empresa de alojamiento, la seguridad es cosa de ellos. No funciona así. El desarrollador y el proveedor de alojamiento tienen sus propias obligaciones, pero usted, como responsable, rinde cuentas ante la autoridad de control y ante sus clientes.

Esto es lo que las normas esperan de usted como propietario, explicado con claridad. No es asesoramiento jurídico: para cualquier caso fuera de lo común, consulte a un abogado o a su delegado de protección de datos.

Quién es quién en su sitio web

El RGPD reparte a los implicados en dos papeles. El responsable del tratamiento decide para qué y cómo se recogen los datos. Ese es su negocio. El encargado del tratamiento trata los datos por cuenta de usted: la empresa de alojamiento en cuyo servidor está la base de datos, el desarrollador o la agencia con acceso al panel de administración, la herramienta de boletines, el sistema de reservas.

Esto tiene consecuencias prácticas. Si la agencia descuida las actualizaciones y alguien roba los envíos del formulario, es usted quien notifica la brecha, informa a sus clientes y responde a las preguntas de la autoridad. Las cuentas con la agencia las ajusta después, según su contrato, si lo tiene.

Artículo 32: una seguridad acorde con el riesgo

El artículo 32 no le dice qué plugin usar ni cuántos caracteres debe tener una contraseña. Pide «medidas técnicas y organizativas apropiadas», es decir, medidas proporcionales al riesgo. Da algunos ejemplos: el cifrado, mantener los datos confidenciales y disponibles, poder restaurarlos rápidamente tras un incidente y comprobar con regularidad si su seguridad funciona de verdad.

En el sitio web de una pequeña empresa eso se traduce en cosas bastante concretas:

• todo el sitio funciona con HTTPS y ningún formulario envía datos por http sin cifrar,
• el CMS, el tema y los plugins se actualizan según un calendario, no cuando alguien se acuerda,
• solo pueden entrar al panel de administración las personas que de verdad lo necesitan, y usan inicio de sesión en dos pasos,
• las copias de seguridad se guardan fuera del servidor del sitio y alguien ha comprobado que la restauración funciona,
• los envíos antiguos del formulario no se guardan años en la base de datos sin motivo,
• cada cierto tiempo alguien revisa el sitio desde fuera, por ejemplo con un escáner de seguridad, y anota el resultado.

El último punto es el que más fácilmente se omite, y sin embargo responde directamente al requisito de «comprobar con regularidad». Si la autoridad le pregunta algún día cómo cuida la seguridad, una nota que diga «revisado el 3 de marzo, dos problemas, corregidos el 10 de marzo» vale más que cualquier garantía de que el sitio probablemente está bien.

72 horas para avisar a la autoridad

Una brecha de datos personales no tiene por qué ser un ataque espectacular. Puede ser una exportación de envíos del formulario que cualquiera podía descargar desde una dirección pública. Una cuenta de administrador secuestrada. Un correo a todos sus clientes enviado con sus direcciones en CC en lugar de CCO.

El artículo 33 dice que el responsable notifica a la autoridad de control sin dilación indebida y, si es posible, en un plazo de 72 horas desde que tenga constancia de la brecha. En Polonia esa autoridad es la UODO, en el Reino Unido la ICO (el UK GDPR mantuvo la misma regla), en Irlanda la Data Protection Commission. Son horas de reloj, así que un fin de semana no las detiene. Solo puede omitir la notificación cuando sea improbable que la brecha suponga un riesgo para las personas cuyos datos están afectados.

Dos cosas deberían hacerlo menos intimidante. No necesita tener el panorama completo de inmediato: las normas permiten facilitar la información por fases, así que es mejor notificar a tiempo lo que sabe y completar el resto después que esperar el informe completo de su desarrollador. Y la mayoría de las autoridades reciben las notificaciones mediante un formulario en línea en su sitio web.

Una notificación tardía tiene que explicar el retraso. Por eso, acuerde con quien cuida su sitio que le informe el mismo día de cualquier sospecha de fuga. El encargado debe avisarle sin dilación indebida, pero la decisión de notificar es suya, y el plazo también.

Cuándo tiene que informar a sus clientes

El artículo 34 va un paso más allá. Si es probable que una brecha suponga un alto riesgo para las personas afectadas, también debe comunicárselo a ellas, de nuevo sin dilación indebida. Con lenguaje claro: qué ha pasado, cuáles son las consecuencias probables, qué ha hecho usted y de qué deben desconfiar, por ejemplo de correos que se hagan pasar por su empresa.

Alto riesgo significa cosas como contraseñas filtradas de cuentas de clientes, números de documento de identidad, información de salud del formulario de registro de una clínica, o la lista de clientes de un despacho de abogados con notas sobre sus casos. Una dirección de correo de una suscripción al boletín suele pesar menos, pero la valoración depende siempre de la situación.

Hay excepciones. No tiene que avisar a las personas si los datos estaban cifrados de forma que ningún tercero pueda leerlos, o si actuó de inmediato de un modo que hace improbable que el alto riesgo se materialice. Cuando contactar a cada persona por separado exigiría un esfuerzo desproporcionado, se puede usar en su lugar una comunicación pública.

Un contrato de encargo con su proveedor de alojamiento y su desarrollador

Quien trate datos personales por cuenta de usted debería tener con usted un contrato de encargo del tratamiento (artículo 28). No tiene que ser un documento extenso. Las empresas de alojamiento grandes y las herramientas de boletines suelen tener un DPA listo en su panel o en sus condiciones de servicio. Usted lo acepta y guarda una copia.

Con autónomos y agencias pequeñas, a menudo nadie lo ha pensado. El contrato establece, entre otras cosas, que tratan los datos solo según sus instrucciones, los mantienen seguros, le ayudan si hay una brecha y borran o devuelven los datos cuando dejan de trabajar juntos. Añada los detalles prácticos: quién es la persona de contacto, por qué canal comunican un incidente y en cuánto tiempo.

Qué conservar por escrito

El RGPD se basa en la responsabilidad proactiva. No basta con cumplir, tiene que poder demostrarlo. Para el sitio web de una empresa eso significa una carpeta, en papel o en una unidad compartida:

1. Los contratos de encargo con su proveedor de alojamiento, su desarrollador o agencia, y cada herramienta que recibe datos de sus formularios.
2. Una breve descripción de su seguridad: qué se actualiza y quién lo hace, dónde están las copias de seguridad, quién tiene acceso de administrador.
3. Los resultados de las revisiones periódicas del sitio y una nota de lo que se hizo con ellos.
4. Un registro de brechas. El artículo 33 exige documentar cada brecha, también las que decide no notificar: qué pasó, qué efectos tuvo y qué hizo usted. Para las no notificadas, anote por qué decidió no hacerlo.
5. Un registro de actividades de tratamiento, si le corresponde. La exención para organizaciones con menos de 250 empleados es más estrecha de lo que parece: no cubre el tratamiento que no es ocasional, y un formulario que trae consultas cada semana difícilmente puede llamarse ocasional.

Nada de esto requiere un gran presupuesto. Requiere un acuerdo claro sobre quién hace qué antes de que pase nada. Durante un incidente, 72 horas pasan muy deprisa, sobre todo si dedica el primer día a averiguar quién tiene acceso al servidor.