El TPV y el software de reservas son dos de las herramientas más críticas de cualquier restaurante. Concentran nombre, teléfono, correo, hora, número de comensales, alergias, tickets, formas de pago, fidelización y, en muchos casos, también los listados del personal. Quien los provee no es un simple vendedor de software: es alguien que trata datos personales del restaurante por su cuenta. Y eso, en términos del RGPD, tiene un nombre concreto y un contrato concreto.
Esta guía repasa el régimen del encargado del tratamiento (art. 28 RGPD) aplicado al sector hostelero: qué tiene que firmar el restaurante con su proveedor, qué garantías debe exigir, qué pasa con los servidores fuera de la UE y qué ocurre con los datos cuando termina el contrato.
Por qué el TPV y el software de reservas son encargados del tratamiento
El RGPD diferencia dos roles claros:
- Responsable del tratamiento (art. 4.7): quien decide los fines y medios del tratamiento. En este caso, el restaurante.
- Encargado del tratamiento (art. 4.8): quien trata datos personales por cuenta del responsable, siguiendo sus instrucciones.
El proveedor del TPV no decide a quién fideliza el restaurante, qué alergia se anota o qué oferta se envía. Ejecuta lo que el responsable necesita: registra tickets, almacena reservas, ofrece reporting. Es encargado del tratamiento. Lo mismo aplica al proveedor del sistema de reservas, al CRM de fidelización, a la gestoría laboral, al proveedor de email transaccional o al proveedor del menú QR si captura datos.
Cuidado con un caso frecuente: si el proveedor reutiliza los datos del restaurante para finalidades propias (analítica agregada, marketing de la propia plataforma, venta de leads), en esa parte ya no actúa como encargado, sino como responsable independiente, y debe tener su propia base jurídica. Conviene leer las condiciones con atención y aclararlo por contrato.
El contrato de encargado: qué debe incluir mínimo (art. 28.3 RGPD)
El art. 28.3 RGPD exige que la relación responsable-encargado se documente en un contrato u otro acto jurídico vinculante, con un contenido mínimo tasado. No es una sugerencia: es un requisito del propio Reglamento. Estos son los puntos que no pueden faltar:
| Apartado | Qué debe regular |
|---|---|
| Objeto y duración | Qué servicio se presta y durante cuánto tiempo trata datos el encargado. |
| Naturaleza y finalidad | Para qué se tratan los datos en el marco del servicio (reservas, TPV, facturación, fidelización…). |
| Tipo de datos y categorías de interesados | Identificativos, contacto, datos económicos, notas vinculadas al servicio (alergias en la comanda), categorías de clientes, empleados, etc. |
| Art. 28.3.a — Instrucciones documentadas | El encargado solo trata datos siguiendo instrucciones documentadas del responsable, incluidas las transferencias internacionales. |
| Art. 28.3.b — Confidencialidad | Las personas autorizadas para tratar los datos se comprometen por contrato o por ley a respetar la confidencialidad. |
| Art. 28.3.c — Medidas de seguridad | Aplicar las medidas del art. 32 RGPD apropiadas al riesgo (cifrado, autenticación, control de accesos, copias de seguridad, capacidad de restaurar). |
| Art. 28.3.d — Subencargados | Régimen de autorización y comunicación al responsable; los subencargados deben asumir las mismas obligaciones de protección de datos. |
| Art. 28.3.e — Asistencia en derechos | Asistir al responsable mediante medidas técnicas y organizativas para atender los derechos de los interesados (arts. 15–22 RGPD). |
| Art. 28.3.f — Cumplimiento auxiliar | Ayudar al responsable a cumplir las obligaciones de los arts. 32–36 RGPD (seguridad, notificación de brechas, EIPD, consulta previa). |
| Art. 28.3.g — Fin del contrato | Devolver o suprimir los datos a elección del responsable y eliminar copias, salvo conservación obligada por ley. |
| Art. 28.3.h — Información y auditoría | Poner a disposición del responsable la información necesaria para demostrar cumplimiento y permitir auditorías o inspecciones. |
Muchos proveedores cuentan con su propio modelo de contrato (DPA, Data Processing Addendum). Eso no exime al restaurante de leerlo: ese DPA debe encajar con el contenido del art. 28.3 RGPD y no contradecirlo.
Subencargados: cuando el proveedor del TPV usa AWS o Azure
La inmensa mayoría de los proveedores de software de reservas y TPV en la nube no alojan ellos mismos los servidores: los contratan a un hiperescalador (Amazon Web Services, Microsoft Azure, Google Cloud). Esos hiperescaladores son subencargados del tratamiento.
El art. 28.2 y 28.4 RGPD exige:
- Autorización del responsable, específica o general (en la práctica, suele formalizarse en el contrato inicial con una lista de subencargados ya aceptados).
- Información previa al responsable de cualquier cambio o incorporación de nuevos subencargados, con oportunidad para oponerse.
- Mismo régimen: el subencargado queda obligado, mediante contrato, a las mismas obligaciones que el encargado principal.
- Responsabilidad ante el responsable: el encargado responde por los incumplimientos de sus subencargados (art. 28.4 RGPD).
Lo recomendable, como responsable, es exigir al proveedor una lista pública y actualizada de subencargados (URL accesible) con país de ubicación y finalidad. Eso facilita la transparencia frente al cliente final y la trazabilidad ante una incidencia.
Ubicación de los servidores y transferencias internacionales
Saber dónde están físicamente los servidores que almacenan las reservas del restaurante es una pregunta concreta y razonable. Las opciones habituales:
- Servidores en la UE / EEE: sin transferencia internacional. Régimen ordinario del RGPD.
- Servidores en países con decisión de adecuación (art. 45 RGPD): por ejemplo, Reino Unido (con régimen específico), Suiza, Canadá (en parte), Japón, Corea del Sur. Transferencia legítima sin garantías adicionales.
- Servidores en EE. UU.: desde julio de 2023, decisión de adecuación basada en el Data Privacy Framework (DPF). Las transferencias a proveedores adheridos al DPF cuentan con cobertura del art. 45 RGPD. Si el proveedor no está adherido, deben aplicarse Cláusulas Contractuales Tipo (art. 46 RGPD) y, según el caso, medidas suplementarias tras una evaluación de impacto de la transferencia (TIA).
- Servidores en otros terceros países sin adecuación: régimen estricto del art. 46 RGPD —Cláusulas Contractuales Tipo, normas corporativas vinculantes— y, en su defecto, supuestos excepcionales del art. 49 RGPD.
En la política de privacidad del restaurante debe constar si existen transferencias internacionales y qué garantía las ampara. Esa información se obtiene del proveedor por contrato; si no la da, hay un problema.
Seguridad de la información: qué debe garantizar el proveedor
El art. 32 RGPD exige medidas técnicas y organizativas apropiadas al riesgo. En un proveedor de TPV o de reservas, eso se traduce, mínimamente, en:
- Cifrado de los datos en tránsito (HTTPS/TLS) y, cuando sea proporcionado, en reposo.
- Autenticación robusta: contraseñas con políticas exigentes y, preferentemente, segundo factor para las cuentas de administración.
- Control de accesos por rol tanto para el personal del restaurante como para el personal interno del proveedor.
- Trazabilidad / logs de acceso y de operaciones sensibles, con plazo razonable de conservación.
- Copias de seguridad y pruebas de restauración documentadas.
- Plan de continuidad y de gestión de incidentes.
- Cumplimiento de estándares reconocidos (ISO/IEC 27001, SOC 2, Esquema Nacional de Seguridad cuando aplique).
- Notificación de brechas al responsable en plazo que le permita cumplir el art. 33 RGPD frente a la AEPD (a efectos prácticos, sin demora indebida y desde luego con margen para las 72 horas orientativas del responsable).
Si el proveedor maneja datos de pago (PAN, fechas, CVV), se suma el cumplimiento del estándar PCI-DSS por la red de medios de pago.
Al terminar el contrato: devolver o exportar, no destruir sin más
Este es uno de los errores más caros en hostelería: cambiar de proveedor de TPV o de reservas y descubrir, semanas después, que el histórico de clientes, reservas y facturación se ha quedado en un sistema al que ya no se accede.
El art. 28.3.g RGPD obliga al encargado, una vez finalizada la prestación, a suprimir o devolver al responsable los datos personales, a elección del responsable, y a suprimir las copias existentes, salvo conservación obligada por ley. La práctica correcta es:
- Pedir la exportación de los datos en un formato útil (CSV, JSON, base de datos estructurada).
- Verificar la integridad de lo exportado antes de dar por cerrada la migración.
- Solicitar por escrito la supresión en los sistemas del proveedor saliente, incluyendo copias de seguridad, en los plazos que el proveedor pueda documentar.
- Conservar evidencia de la exportación y de la solicitud de supresión.
El restaurante necesita esos datos para cumplir con sus propios plazos legales —fiscales, laborales, contables— y para no perder su historial de clientela. Un proveedor que solo ofrezca destruir sin permitir la exportación previa no cumple con el art. 28.3.g; uno serio facilita esa salida.
La normativa autonómica y sectorial puede afectar a los plazos de conservación que el responsable deba aplicar tras recibir los datos.
Auditorías y derechos de inspección
El art. 28.3.h RGPD reconoce al responsable el derecho a obtener del encargado toda la información necesaria para demostrar el cumplimiento, y a realizar auditorías, incluidas inspecciones, por sí mismo o por un auditor autorizado. Cómo se ejerce esto sin colapsar a un proveedor con cientos de restaurantes-cliente:
- Certificaciones reconocidas (ISO/IEC 27001, SOC 2, ENS Medio o Alto, Esquema Privacy by Design): el proveedor las pone a disposición.
- Informes de auditoría independientes (SOC 2 tipo II, por ejemplo) sobre los controles relevantes.
- Cuestionarios de seguridad y privacidad respondidos por el proveedor.
- Auditoría in situ, reservada para situaciones con causa justificada y con preaviso razonable.
El contrato debe explicitar el cauce y la frecuencia. Negarse en bloque a cualquier mecanismo de auditoría es incompatible con el art. 28.
Cómo elegir un proveedor responsable: checklist
| # | Qué verificar antes de firmar |
|---|---|
| □ | Tiene contrato de encargado (DPA) que cumple el art. 28.3 RGPD. |
| □ | Identifica al responsable interno de protección de datos (nombre o función + correo de contacto). |
| □ | Publica la lista de subencargados y notifica cambios. |
| □ | Indica la ubicación de los servidores y, si hay transferencias internacionales, la base jurídica (decisión de adecuación, DPF, CCT). |
| □ | Describe sus medidas de seguridad (cifrado, autenticación, accesos por rol, logs, copias de seguridad). |
| □ | Cuenta con certificaciones reconocidas o informes equivalentes. |
| □ | Notifica brechas al responsable sin demora indebida. |
| □ | Permite exportar los datos en formato útil al final del contrato y solo después los suprime. |
| □ | No reutiliza los datos del restaurante para finalidades propias sin base jurídica adecuada e independiente. |
| □ | Habilita un cauce de auditoría proporcionado y documentado. |
El TPV y el sistema de reservas son herramientas críticas para la operativa diaria, pero también activos de información sensible. Elegir bien al proveedor, firmar el contrato adecuado y tener clara la salida es lo que convierte la protección de datos en parte del oficio, y no en una preocupación añadida.
"El día que cambias de TPV descubres si firmaste un buen contrato. Si tu proveedor solo sabe borrar, no es un encargado serio; un encargado serio te devuelve los datos antes."
Mario P. Talamillo · Socio director, Certix®
Si tienes un restaurante o grupo de restauración y quieres revisar tu documentación de protección de datos, en Certix trabajamos específicamente con hostelería. Sin comerciales: desde el primer contacto, hablarás con un especialista.
Guía de protección de datos para restaurantes
Este contenido es meramente orientativo y divulgativo; no constituye en ningún caso asesoramiento jurídico especializado. La normativa autonómica sectorial puede ampliar o modificar los plazos y requisitos de la norma estatal. La aplicación de la normativa a cada caso concreto requiere análisis individualizado.