RGPD para páginas web, formularios y servicios digitales en Málaga

Qué exige el RGPD a una página web de empresa

Una página web puede tratar datos personales incluso cuando no existe una tienda online: formularios de contacto, solicitudes de presupuesto, reservas, mensajes de WhatsApp, registros técnicos del servidor, newsletters o herramientas de medición pueden implicar tratamientos diferentes. El primer paso es identificar los datos, finalidades y participantes reales en cada recorrido del usuario, no limitarse a colocar un aviso de privacidad.

La revisión combina el RGPD, la LOPDGDD y, cuando procede, la Ley de Servicios de la Sociedad de la Información y de Comercio Electrónico (LSSI). Las obligaciones cambian según se ofrezcan servicios profesionales, venta a distancia, formularios simples, contenido incrustado o campañas comerciales.

Inventario de datos y recorridos digitales

Conviene trazar el recorrido completo de la información: desde que alguien entra en la web hasta que se recibe un correo, se crea un cliente en el CRM, se envía un presupuesto o se reserva una cita. Hay que identificar responsable, finalidades, base jurídica, destinatarios, conservaciones y medidas de seguridad por cada actividad.

Por ejemplo, un formulario puede recoger nombre, correo, teléfono y detalles de una consulta. Sin embargo, los datos pueden terminar también en un buzón de correo, la base del proveedor de formularios, una copia de seguridad y el programa de gestión. No todos esos actores cumplen necesariamente el mismo papel jurídico; su relación debe analizarse.

Aviso legal: identificación del titular

La LSSI exige que el prestador ofrezca información de identificación y contacto de manera permanente, fácil, directa y gratuita, con las particularidades aplicables a cada actividad. Según el caso puede incluir denominación social, domicilio o establecimiento permanente, correo electrónico, datos registrales y otros extremos previstos legalmente.

El aviso legal no sustituye a la política de privacidad ni a las condiciones de contratación. Debe describir al verdadero titular del sitio y no a la empresa que lo diseñó. Conviene revisarlo cuando cambien razón social, domicilio, datos mercantiles o canales de contacto.

Política de privacidad clara y ajustada a los tratamientos

La política debe explicar, de forma comprensible, quién es responsable, qué datos se recogen, para qué, la base jurídica, destinatarios, transferencias si las hay, criterios de conservación, derechos y medios de contacto. La información del artículo 13 del RGPD no se cumple mediante una plantilla genérica sin correspondencia con la operativa real.

Si existen procesos muy distintos —por ejemplo, solicitudes comerciales, contratación y selección de personal— puede ser útil separar capas o apartados. También hay que identificar cambios de herramientas, plataformas de terceros o nuevas finalidades, para que el texto refleje lo que la web hace hoy.

Información por capas en formularios

En la propia recogida es recomendable mostrar una primera capa breve con los datos esenciales del responsable, la finalidad, la base jurídica cuando corresponda, la posibilidad de ejercer derechos y un enlace visible a la información completa. El usuario debe poder conocer las condiciones antes de enviar su información.

La segunda capa amplía el resto de extremos exigibles, sin hacer depender el acceso a información fundamental de casillas oscuras o textos ilegibles. Un enlace escondido en el pie de página no necesariamente resuelve la falta de información junto al formulario.

Formularios de contacto y presupuestos

Los campos deben ser adecuados, pertinentes y limitados a lo necesario. Un formulario de presupuesto no debería exigir fecha de nacimiento o DNI si esos datos no son necesarios para atender la consulta. Es preferible marcar claramente los campos obligatorios y explicar la finalidad de cada dato solicitado.

La base jurídica puede variar: actuaciones precontractuales cuando la persona solicita un presupuesto, interés legítimo en circunstancias justificadas o consentimiento si se solicita para una finalidad distinta. No todos los formularios exigen una casilla de consentimiento; lo esencial es identificar la base correcta, informar y evitar que una aceptación comercial sea condición para contactar.

Consentimiento y casillas: cuándo son necesarias

Cuando una finalidad se apoya en el consentimiento, debe ser libre, específico, informado e inequívoco. No son válidas casillas premarcadas ni fórmulas que mezclan distintas finalidades incompatibles, como gestionar una consulta y suscribir automáticamente al usuario a campañas publicitarias.

Es importante registrar la prueba del consentimiento cuando proceda: versión informativa mostrada, fecha, finalidad y mecanismo de obtención. La aceptación de la política de privacidad como si fuera un contrato no sustituye por sí sola a la información y a la base jurídica del tratamiento.

Cuando el formulario recoge datos de salud u otros datos sensibles

Una pregunta sobre alergias, embarazo, diagnóstico o tratamientos médicos puede introducir categorías especiales de datos del artículo 9 del RGPD. No basta con una política general o un texto que afirme que la web solo recoge información identificativa.

Debe existir una base del artículo 6 y una condición válida del artículo 9, junto con minimización, permisos, conservación y seguridad reforzadas cuando proceda. Antes de pedir información clínica en una web de bienestar o reserva, conviene analizar si se necesita realmente ese nivel de detalle.

Cookies y tecnologías similares: análisis real

La política de cookies y el panel de consentimiento deben responder a los rastreadores que efectivamente se utilizan: propios, de terceros, técnicos, analíticos, publicitarios o de personalización. Las tecnologías exentas de consentimiento no equivalen a una exención general de información o del RGPD si tratan datos personales.

Para tecnologías no exentas, la AEPD exige consentimiento previo e informado y que las opciones de aceptar y rechazar se ofrezcan de forma equiparable. La simple navegación, la inactividad o un botón de cierre ambiguo no son un consentimiento válido.

Diseño correcto del banner y retirada del consentimiento

El aviso inicial debe informar de manera concisa, permitir aceptar y rechazar con una prominencia comparable y conducir a una segunda capa detallada. Si existen varias finalidades sujetas a consentimiento, procede valorar una configuración granular adecuada.

El rechazo debe impedir la activación de tecnologías no necesarias y la decisión debe respetarse al cambiar de página. Además, quien consintió tiene que poder retirar o cambiar esa decisión de forma sencilla. Un banner visualmente correcto no cumple si la web carga primero los scripts y pregunta después.

Analytics, píxeles publicitarios y gestores de etiquetas

Google Analytics, píxeles de publicidad y herramientas de gestión de etiquetas pueden desplegar identificadores y enviar información a proveedores externos. El gestor de etiquetas no debería convertirse en una vía para cargar herramientas sin inventariarlas ni someterlas al consentimiento cuando sea exigible.

Hay que identificar scripts, finalidades, configuraciones, terceros, conservación y posibles transferencias, así como comprobar que el bloqueo anterior al consentimiento funciona realmente en una sesión limpia. Incluso una medición configurada para reducir datos requiere analizar su funcionamiento efectivo.

reCAPTCHA, antispam y protección de formularios

Los sistemas antispam pueden ser necesarios para proteger formularios, pero su integración no debe tratarse automáticamente como neutral desde la perspectiva de privacidad. Algunas soluciones recogen información técnica o se comunican con terceros al cargar la página, antes incluso de que se envíe el formulario.

Debe analizarse el producto, su configuración, los datos implicados, la base jurídica y si utiliza tecnologías sujetas a consentimiento. Cuando sea posible, valorar cargas condicionadas, alternativas menos intrusivas y medidas técnicas complementarias como limitación de solicitudes o validación del servidor.

Mapas, vídeos incrustados, tipografías y widgets

Insertar un mapa, un reproductor de vídeo, un chat, fuentes remotas o un widget social puede provocar solicitudes a dominios externos y transmitir identificadores, IP u otra información técnica. Que la página no tenga formularios no significa necesariamente que no existan tratamientos.

Se deben revisar las peticiones de red y la política real de cada proveedor. Si una integración necesita consentimiento, una solución práctica puede consistir en mostrar una vista previa local y cargar el recurso externo solo tras una acción informada del usuario.

WhatsApp, chats y atención por mensajería

Un botón de WhatsApp puede abrir un canal externo y, según cómo esté implementado, cargar recursos adicionales. La empresa debe informar de las finalidades y del uso de servicios de mensajería, controlar las personas que tienen acceso y evitar utilizar conversaciones comerciales para nuevas finalidades sin evaluación.

Si el usuario envía documentos, imágenes o datos de salud, la protección necesaria aumenta. La integración de un chat no sustituye a un canal seguro para la transmisión de información especialmente sensible.

Reservas online y gestión de citas

Una reserva puede contener identificación, horarios, servicios contratados, preferencias u observaciones. Hay que revisar qué datos recoge la web, qué datos recibe la plataforma de reservas, quién gestiona las confirmaciones y si intervienen integraciones de calendario, correo o SMS.

Debe determinarse si el proveedor actúa por cuenta de la empresa, como responsable independiente o mediante otra configuración de roles. Una plataforma de reservas no es automáticamente «encargado» por el solo hecho de contratarse, ni toda comunicación de datos constituye una cesión prohibida.

Tiendas online y procesos de compra

Una tienda añade cuentas de usuario, cesta, pedidos, facturación, devoluciones, pagos, mensajería y prevención de fraude. El cumplimiento requiere distinguir los tratamientos necesarios para la compraventa de aquellos usados para perfiles, análisis comercial o publicidad.

Además del RGPD pueden ser aplicables obligaciones de comercio electrónico, información de consumo y contratación a distancia. El botón de compra, las condiciones, los plazos y las comunicaciones posteriores deben analizarse en conjunto, no como simples complementos legales del pie de página.

Pasarelas de pago y datos bancarios

La empresa debe identificar qué información trata directamente y qué datos quedan bajo el control de la pasarela de pagos. Utilizar un proveedor externo puede reducir la exposición de datos de tarjeta, pero no elimina el deber de informar ni la necesidad de revisar las relaciones y las medidas de seguridad.

Evita almacenar información bancaria o de tarjetas más allá de lo necesario. La confirmación del pedido, los reembolsos y la prevención del fraude requieren un análisis propio de finalidad, base y conservación.

Newsletter y comunicaciones comerciales

Suscribirse a una newsletter debe ser una decisión diferenciada de enviar un formulario o adquirir un servicio, salvo supuestos legalmente permitidos con condiciones específicas. La LSSI regula las comunicaciones comerciales electrónicas y su oposición o baja gratuita y sencilla.

Si se utiliza una herramienta de mailing, revisa listas, fuentes de alta, pruebas de autorización, transferencias y contratos aplicables. No importes sin evaluación la agenda de contactos del móvil ni utilices una casilla genérica para mezclar comunicaciones de varias marcas o finalidades.

CRM, automatizaciones y perfiles comerciales

Los formularios se integran cada vez más con CRM, automatizadores, asistentes IA y herramientas que asignan puntuaciones o segmentan clientes. Esto multiplica los destinos y los periodos de conservación, y puede generar inferencias personales a partir de datos aparentemente simples.

Documenta las conexiones, elimina campos innecesarios y comprueba quién recibe cada evento. Si se adoptan decisiones exclusivamente automatizadas con efectos jurídicos o significativamente similares, se necesitan análisis y garantías adicionales conforme al artículo 22 del RGPD.

Hosting, servidores, backups y accesos técnicos

El proveedor de alojamiento puede tener acceso lógico o físico a bases de datos, copias, registros y cuentas. La empresa debe revisar sus condiciones, los acuerdos aplicables, subencargados, localización, políticas de copias y mecanismos de borrado y recuperación.

Un servidor situado en la Unión Europea no demuestra por sí solo que no existan transferencias o accesos desde terceros países. También importan el soporte remoto, la administración del servicio y la cadena de proveedores subcontratados.

Agencias web, desarrolladores y mantenimiento

Quien desarrolla o mantiene la web puede acceder a formularios, buzones, bases de datos, backups, claves y analítica. Hay que distinguir la prestación sin acceso a datos de aquella en la que el profesional trata información personal por cuenta del titular.

Es recomendable usar cuentas nominativas, permisos mínimos, entornos de pruebas anonimizados, control de cambios y procedimientos de devolución o eliminación de accesos. Compartir la contraseña principal del hosting con varios colaboradores incrementa riesgos innecesarios.

Servicios internacionales y transferencias de datos

Las herramientas cloud pueden implicar proveedores establecidos fuera del Espacio Económico Europeo o accesos internacionales. Cuando existe una transferencia sujeta al capítulo V del RGPD, deben estudiarse el mecanismo aplicable y, cuando proceda, las garantías complementarias necesarias.

No basta con afirmar que el proveedor es conocido o que el centro de datos está en Europa. Hay que verificar qué entidades participan, desde dónde acceden y qué documentación contractual y de cumplimiento proporciona el servicio.

Seguridad web: HTTPS no es suficiente

HTTPS protege el transporte, pero no evita por sí solo accesos indebidos, plugins vulnerables, contraseñas débiles, cuentas abandonadas o formularios que almacenan información innecesaria. La seguridad del artículo 32 del RGPD es proporcional al riesgo y se adapta a la arquitectura y el tipo de datos.

Entre las medidas habituales están las actualizaciones, MFA, backups probados, protección de credenciales, permisos mínimos, registros adecuados, monitorización de incidencias y revisión del código y de las integraciones. Debe verificarse también cómo se gestionan los datos de prueba y las copias.

Brechas de seguridad originadas en una web

Una inyección, una cuenta comprometida, una fuga de base de datos, un formulario publicado por error o el envío de información a destinatarios equivocados pueden dar lugar a una brecha de datos personales. Un incidente informático no equivale siempre a una brecha y una brecha no requiere notificación automática en todos los casos.

La empresa debe contener, documentar y evaluar el riesgo para las personas. Cuando sea probable un riesgo para derechos y libertades, el responsable debe notificar a la AEPD sin dilación indebida y, cuando sea posible, dentro de las 72 horas; la comunicación a los afectados se analiza separadamente cuando exista alto riesgo. Consulta nuestra guía de brechas de datos personales.

Ejercicio de derechos desde canales digitales

Las personas pueden solicitar acceso, rectificación, supresión, oposición, limitación u otros derechos que correspondan. El responsable debe facilitar vías de contacto y un procedimiento real para localizar la información en web, CRM, correo, plataformas de reservas y otros sistemas.

El plazo general de respuesta del RGPD es de un mes desde la recepción, con posible ampliación de dos meses en casos complejos bajo las condiciones legales. La empresa debe gestionar identidad de forma proporcionada y conservar evidencias de las actuaciones realizadas.

Conservación, borrado y copias de seguridad

No existe un periodo universal de conservación de todos los formularios web. Depende de la finalidad, las obligaciones legales, posibles responsabilidades y otras circunstancias de cada tratamiento. Es importante definir cuándo dejan de ser necesarias las consultas, leads o reservas no convertidas.

El borrado debe contemplar bases de datos, buzones, CRM, plataformas externas y copias, con procedimientos técnicos razonables. Las copias de seguridad pueden requerir calendarios de purga y acceso restringido; no deberían convertirse en un archivo indefinido y sin control.

Cómo revisar una web antes de publicar

Una revisión útil combina documentación y pruebas reales en navegador: analizar cookies en modo privado, comprobar el bloqueo de scripts, enviar un formulario de prueba, verificar la primera capa de información, revisar los destinatarios del mensaje y observar las peticiones a terceros.

También conviene comprobar las políticas de privacidad, la correcta identificación legal, el flujo de reservas, los proveedores, la seguridad de acceso al panel y la eliminación de datos. La conformidad no se deduce únicamente de ver un botón «Aceptar» o un enlace a la política.

Errores frecuentes en páginas web de empresas

• Copiar textos legales de otra web sin inventariar tratamientos.
• Activar cookies de medición o publicidad antes de obtener consentimiento válido.
• Mostrar solo «Aceptar» o hacer menos visible «Rechazar».
• Unir el consentimiento comercial con la solicitud de presupuesto.
• Decir que no hay terceros mientras existen hosting, correo, reservas y píxeles.
• Guardar indefinidamente mensajes y fichas de clientes.
• Usar contraseñas compartidas en administración y correo.
• Instalar widgets, mapas o vídeos sin revisar las solicitudes externas.
• Confundir un certificado SSL con una adaptación RGPD.

La mayoría de estos fallos se corrigen mejor con una revisión de arquitectura y procesos que añadiendo más texto genérico al pie de página.

Nuestro método de adaptación RGPD para webs y negocios digitales

En RGPD Málaga comenzamos inventariando la web, su responsable y sus herramientas. Después identificamos formularios, cookies, pasarelas, reservas, mensajería y proveedores; revisamos su base jurídica y sus riesgos; y definimos información, consentimiento y controles técnicos ajustados al servicio.

La fase final comprende pruebas reales de carga de scripts, funcionamiento de formularios y conservación, revisión documental y una pauta de mantenimiento para cuando se incorporen nuevos plugins, campañas o plataformas. Podemos coordinar la parte jurídica y técnica con el desarrollador que lleve la web.

Este trabajo se relaciona con nuestra adaptación RGPD para empresas, la revisión de proveedores y encargados y las medidas técnicas y organizativas.