Cuando una organización realiza una votación online, cede a su proveedor tecnológico datos de sus miembros: nombres, correos, en muchos casos pertenencia sindical o ideología política. Esto tiene consecuencias legales precisas que muchas plataformas de voto — y muchos clientes — ignoran sistemáticamente.
Los censos electorales son datos de categoría especial
El Reglamento General de Protección de Datos (RGPD) distingue entre datos personales ordinarios y datos de categoría especial (Art. 9), que requieren medidas de protección reforzadas. Entre ellos: datos que revelen ideología política, afiliación sindical o creencias religiosas.
Un censo electoral no es un directorio de contactos neutro. En el momento en que una persona aparece en el censo de una votación sindical, de un partido político o de una asamblea de miembros, ese dato revela por contexto su pertenencia o simpatía con esa organización. Aunque el dato aislado sea solo un nombre y un email, el contexto lo convierte en categoría especial.
Responsable del tratamiento vs. encargado del tratamiento
El RGPD establece una distinción fundamental entre quien decide para qué se tratan los datos (responsable) y quien los procesa por cuenta de otro (encargado). En una votación online:
- Tu organización es el responsable: decides quién está en el censo, qué se vota, durante cuánto tiempo se conservan los datos.
- La plataforma de votaciones es el encargado: almacena y procesa esos datos siguiendo tus instrucciones, pero no tiene decisión sobre ellos.
Esto significa que la relación entre tu organización y tu plataforma de voto debe estar regulada por contrato. Sin ese contrato, ambas partes incumplen el RGPD — independientemente de lo que diga la política de privacidad genérica.
El contrato DPA: qué es y por qué es obligatorio
El Artículo 28 del RGPD exige un Acuerdo de Encargo de Tratamiento (Data Processing Agreement o DPA) entre el responsable y cualquier encargado que acceda a datos personales. No es opcional ni una formalidad: su ausencia es una infracción directamente sancionable por la AEPD.
El DPA debe recoger, como mínimo:
- Qué datos se tratan, con qué finalidad y durante cuánto tiempo.
- Que el encargado solo actúa siguiendo instrucciones documentadas del responsable.
- Las medidas técnicas y organizativas de seguridad implementadas.
- La lista de subencargados autorizados (backups, monitorización, CDN…) y la garantía de que también están sujetos al DPA.
- El compromiso de devolver o destruir los datos al finalizar la relación.
Infraestructura: todo dentro del EEE
El RGPD prohíbe transferir datos personales fuera del Espacio Económico Europeo salvo con garantías específicas (cláusulas contractuales tipo, decisiones de adecuación, etc.). Para datos de categoría especial, el escrutinio es aún mayor.
Esto afecta a más puntos de lo que parece:
- El servidor principal donde se aloja la aplicación.
- Los servidores de backup donde se almacenan copias de seguridad automáticas.
- Los subcontratistas del proveedor: sistemas de monitorización, CDN, almacenamiento de objetos…
Un proveedor cuyo nodo está en España pero cuyo sistema de backups replica en AWS us-east-1 está transfiriendo datos fuera del EEE. Exige confirmación explícita de cada uno de estos puntos por escrito — no en la FAQ, en el contrato.
Cifrado en reposo: qué debes pedir y a quién
El RGPD no prescribe tecnologías concretas, pero sí exige "medidas técnicas apropiadas" para proteger los datos almacenados. Para datos de categoría especial, el cifrado en reposo es prácticamente ineludible en cualquier análisis de riesgo serio.
Hay dos enfoques habituales en entornos de base de datos:
- Cifrado de disco completo (LUKS): se cifra el volumen donde reside la base de datos a nivel de sistema operativo. Protege ante acceso físico al hardware, pero no ante acceso lógico con credenciales válidas.
- Cifrado a nivel de base de datos (MariaDB TDE / InnoDB Encryption): los ficheros de datos están cifrados internamente. Más granular, no depende de la capa de sistema operativo.
La pregunta importante no es solo si está disponible, sino quién lo configura y quién lo mantiene. En un servicio "administrado", si la responsabilidad recae sobre el cliente y este no lo activa, la protección no existe.
Logs de acceso y trazabilidad del personal del proveedor
Si un técnico del proveedor accede por SSH a tu servidor, está accediendo a datos personales de tus votantes. El RGPD exige que ese acceso sea auditable. Necesitas saber:
- Si el sistema operativo y la base de datos mantienen logs de autenticación activos en todo momento.
- Si tienes acceso a esos logs como cliente — no solo el proveedor — para poder aportarlos ante una auditoría de la AEPD.
- Si cada acceso del personal técnico al servidor queda registrado individualmente, no solo como "acceso del equipo de soporte".
Un proveedor que no puede garantizar esto no puede ser encargado del tratamiento de datos de categoría especial.
Notificación de brechas: la regla de las 72 horas
El Art. 33 del RGPD obliga al responsable del tratamiento a notificar cualquier brecha de seguridad a la AEPD en un máximo de 72 horas desde que tenga conocimiento de ella. Si la brecha ocurre en la infraestructura del proveedor, el reloj empieza a correr desde que el proveedor la detecta — aunque tú aún no lo sepas.
Esto significa que el DPA debe recoger explícitamente:
- El procedimiento y plazo de notificación del proveedor al cliente ante incidentes de seguridad en su infraestructura.
- Si el proveedor garantiza la notificación dentro de un plazo que te permita cumplir con las 72 horas.
- Si dispone de un protocolo documentado de respuesta a incidentes.
Checklist para evaluar un proveedor de votaciones
Antes de firmar con cualquier plataforma de voto online, confirma por escrito cada uno de estos puntos:
- ¿Dispone de DPA estándar que cubra datos de categoría especial (Art. 9 RGPD)?
- ¿El servidor principal y los backups están en el EEE?
- ¿Los subencargados (backups, monitorización, CDN) también operan en el EEE y están sujetos al DPA?
- ¿El cifrado en reposo está activo por defecto o es opcional bajo configuración del cliente?
- ¿Tienes acceso completo a los logs de sistema y de base de datos?
- ¿Los accesos del personal técnico al servidor quedan registrados individualmente?
- ¿El proveedor garantiza notificación de brechas en menos de 24 h para que puedas cumplir las 72 h ante la AEPD?
- ¿Dispone de certificaciones de seguridad vigentes (ISO 27001, ENS, SOC 2)?
- ¿Hay separación técnica real entre los datos de distintos clientes (multi-tenancy seguro)?
Cómo lo gestionamos en demokratian
demokratian es un SaaS: tú no gestionas servidores, no configuras LUKS, no redactas un DPA con tu hosting. Nosotros somos los encargados del tratamiento, y asumimos esa responsabilidad contractualmente.
- Infraestructura 100 % en la UE: servidores y backups en centros de datos ubicados en el Espacio Económico Europeo.
- DPA disponible para todos los clientes — incluidos los que procesan datos de categoría especial.
- Separación real de datos: cada espacio de votación tiene su propia base de datos aislada. Un fallo de un cliente no expone los datos de otro.
- Voto separado del votante por diseño: incluso internamente, no es posible relacionar un voto con la identidad de quien lo emitió.
- Protocolo de notificación de brechas en menos de 24 horas al cliente.
Si necesitas el DPA para tu proceso de homologación de proveedores o tu auditoría interna, escríbenos a hola@demokratian.app.