O TPV e o software de reservas son dúas das ferramentas máis críticas de calquera restaurante. Concentran nome, teléfono, correo, hora, número de comensais, alerxias, tickets, formas de pagamento, fidelización e, en moitos casos, tamén as listaxes do persoal. Quen os provexe non é un simple vendedor de software: é alguén que trata datos persoais do restaurante pola súa conta. E iso, nos termos do RGPD, ten un nome concreto e un contrato concreto.
Esta guía repasa o réxime do encargado do tratamento (art. 28 RGPD) aplicado ao sector hostaleiro: que ten que asinar o restaurante co seu provedor, que garantías debe esixir, que pasa cos servidores fóra da UE e que ocorre cos datos cando termina o contrato.
Por que o TPV e o software de reservas son encargados do tratamento
O RGPD diferencia dous roles claros:
- Responsable do tratamento (art. 4.7): quen decide os fins e medios do tratamento. Neste caso, o restaurante.
- Encargado do tratamento (art. 4.8): quen trata datos persoais por conta do responsable, seguindo as súas instrucións.
O provedor do TPV non decide a quen fideliza o restaurante, que alerxia se anota ou que oferta se envía. Executa o que o responsable necesita: rexistra tickets, almacena reservas, ofrece reporting. É encargado do tratamento. O mesmo aplica ao provedor do sistema de reservas, ao CRM de fidelización, á xestoría laboral, ao provedor de email transaccional ou ao provedor do menú QR se captura datos.
Coidado cun caso frecuente: se o provedor reutiliza os datos do restaurante para finalidades propias (analítica agregada, marketing da propia plataforma, venda de leads), nesa parte xa non actúa como encargado, senón como responsable independente, e debe ter a súa propia base xurídica. Convén ler as condicións con atención e aclaralo por contrato.
O contrato de encargado: que debe incluír como mínimo (art. 28.3 RGPD)
O art. 28.3 RGPD esixe que a relación responsable-encargado se documente nun contrato ou outro acto xurídico vinculante, cun contido mínimo taxado. Non é unha suxestión: é un requisito do propio Regulamento. Estes son os puntos que non poden faltar:
| Apartado | Que debe regular |
|---|---|
| Obxecto e duración | Que servizo se presta e durante canto tempo trata datos o encargado. |
| Natureza e finalidade | Para que se tratan os datos no marco do servizo (reservas, TPV, facturación, fidelización…). |
| Tipo de datos e categorías de interesados | Identificativos, contacto, datos económicos, notas vinculadas ao servizo (alerxias na comanda), categorías de clientes, empregados, etc. |
| Art. 28.3.a — Instrucións documentadas | O encargado só trata datos seguindo instrucións documentadas do responsable, incluídas as transferencias internacionais. |
| Art. 28.3.b — Confidencialidade | As persoas autorizadas para tratar os datos comprométense por contrato ou por lei a respectar a confidencialidade. |
| Art. 28.3.c — Medidas de seguridade | Aplicar as medidas do art. 32 RGPD apropiadas ao risco (cifrado, autenticación, control de accesos, copias de seguridade, capacidade de restaurar). |
| Art. 28.3.d — Subencargados | Réxime de autorización e comunicación ao responsable; os subencargados deben asumir as mesmas obrigas de protección de datos. |
| Art. 28.3.e — Asistencia en dereitos | Asistir ao responsable mediante medidas técnicas e organizativas para atender os dereitos das persoas interesadas (arts. 15–22 RGPD). |
| Art. 28.3.f — Cumprimento auxiliar | Axudar ao responsable a cumprir as obrigas dos arts. 32–36 RGPD (seguridade, notificación de brechas, EIPD, consulta previa). |
| Art. 28.3.g — Fin do contrato | Devolver ou suprimir os datos a elección do responsable e eliminar copias, salvo conservación obrigada por lei. |
| Art. 28.3.h — Información e auditoría | Poñer á disposición do responsable a información necesaria para demostrar cumprimento e permitir auditorías ou inspeccións. |
Moitos provedores contan co seu propio modelo de contrato (DPA, Data Processing Addendum). Iso non exime ao restaurante de lelo: ese DPA debe encaixar co contido do art. 28.3 RGPD e non contradicilo.
Subencargados: cando o provedor do TPV usa AWS ou Azure
A inmensa maioría dos provedores de software de reservas e TPV na nube non aloxan eles mesmos os servidores: contrátanos a un hiperescalador (Amazon Web Services, Microsoft Azure, Google Cloud). Eses hiperescaladores son subencargados do tratamento.
O art. 28.2 e 28.4 RGPD esixe:
- Autorización do responsable, específica ou xeral (na práctica, adoita formalizarse no contrato inicial cunha lista de subencargados xa aceptados).
- Información previa ao responsable de calquera cambio ou incorporación de novos subencargados, con oportunidade para oporse.
- Mesmo réxime: o subencargado queda obrigado, mediante contrato, ás mesmas obrigas que o encargado principal.
- Responsabilidade ante o responsable: o encargado responde polos incumprimentos dos seus subencargados (art. 28.4 RGPD).
O recomendable, como responsable, é esixir ao provedor unha lista pública e actualizada de subencargados (URL accesible) con país de ubicación e finalidade. Iso facilita a transparencia fronte ao cliente final e a trazabilidade ante unha incidencia.
Ubicación dos servidores e transferencias internacionais
Saber onde están fisicamente os servidores que almacenan as reservas do restaurante é unha pregunta concreta e razoable. As opcións habituais:
- Servidores na UE / EEE: sen transferencia internacional. Réxime ordinario do RGPD.
- Servidores en países con decisión de adecuación (art. 45 RGPD): por exemplo, Reino Unido (con réxime específico), Suíza, Canadá (en parte), Xapón, Corea do Sur. Transferencia lexítima sen garantías adicionais.
- Servidores en EE. UU.: desde xullo de 2023, decisión de adecuación baseada no Data Privacy Framework (DPF). As transferencias a provedores adheridos ao DPF contan con cobertura do art. 45 RGPD. Se o provedor non está adherido, deben aplicarse Cláusulas Contractuais Tipo (art. 46 RGPD) e, segundo o caso, medidas suplementarias tras unha avaliación de impacto da transferencia (TIA).
- Servidores noutros terceiros países sen adecuación: réxime estrito do art. 46 RGPD —Cláusulas Contractuais Tipo, normas corporativas vinculantes— e, na súa falta, supostos excepcionais do art. 49 RGPD.
Na política de privacidade do restaurante debe constar se existen transferencias internacionais e que garantía as ampara. Esa información obtense do provedor por contrato; se non a dá, hai un problema.
Seguridade da información: que debe garantir o provedor
O art. 32 RGPD esixe medidas técnicas e organizativas apropiadas ao risco. Nun provedor de TPV ou de reservas, iso tradúcese, minimamente, en:
- Cifrado dos datos en tránsito (HTTPS/TLS) e, cando sexa proporcionado, en repouso.
- Autenticación robusta: contrasinais con políticas esixentes e, preferentemente, segundo factor para as contas de administración.
- Control de accesos por rol tanto para o persoal do restaurante como para o persoal interno do provedor.
- Trazabilidade / logs de acceso e de operacións sensibles, con prazo razoable de conservación.
- Copias de seguridade e probas de restauración documentadas.
- Plan de continuidade e de xestión de incidentes.
- Cumprimento de estándares recoñecidos (ISO/IEC 27001, SOC 2, Esquema Nacional de Seguridade cando aplique).
- Notificación de brechas ao responsable en prazo que lle permita cumprir o art. 33 RGPD fronte á AEPD (a efectos prácticos, sen demora indebida e desde logo con marxe para as 72 horas orientativas do responsable).
Se o provedor manexa datos de pagamento (PAN, datas, CVV), súmase o cumprimento do estándar PCI-DSS pola rede de medios de pagamento.
Ao terminar o contrato: devolver ou exportar, non destruír sen máis
Este é un dos erros máis caros en hostalaría: cambiar de provedor de TPV ou de reservas e descubrir, semanas despois, que o histórico de clientes, reservas e facturación quedou nun sistema ao que xa non se accede.
O art. 28.3.g RGPD obriga ao encargado, unha vez finalizada a prestación, a suprimir ou devolver ao responsable os datos persoais, a elección do responsable, e a suprimir as copias existentes, salvo conservación obrigada por lei. A práctica correcta é:
- Pedir a exportación dos datos nun formato útil (CSV, JSON, base de datos estruturada).
- Verificar a integridade do exportado antes de dar por pechada a migración.
- Solicitar por escrito a supresión nos sistemas do provedor saínte, incluíndo copias de seguridade, nos prazos que o provedor poida documentar.
- Conservar evidencia da exportación e da solicitude de supresión.
O restaurante necesita eses datos para cumprir cos seus propios prazos legais —fiscais, laborais, contables— e para non perder o seu historial de clientela. Un provedor que só ofreza destruír sen permitir a exportación previa non cumpre co art. 28.3.g; un serio facilita esa saída.
A normativa autonómica e sectorial pode afectar aos prazos de conservación que o responsable deba aplicar tras recibir os datos.
Auditorías e dereitos de inspección
O art. 28.3.h RGPD recoñece ao responsable o dereito a obter do encargado toda a información necesaria para demostrar o cumprimento, e a realizar auditorías, incluídas inspeccións, por si mesmo ou por un auditor autorizado. Como se exerce isto sen colapsar a un provedor con centos de restaurantes-cliente:
- Certificacións recoñecidas (ISO/IEC 27001, SOC 2, ENS Medio ou Alto, Esquema Privacy by Design): o provedor pono á disposición.
- Informes de auditoría independentes (SOC 2 tipo II, por exemplo) sobre os controis relevantes.
- Cuestionarios de seguridade e privacidade respondidos polo provedor.
- Auditoría in situ, reservada para situacións con causa xustificada e con preaviso razoable.
O contrato debe explicitar a canle e a frecuencia. Negarse en bloque a calquera mecanismo de auditoría é incompatible co art. 28.
Como elixir un provedor responsable: checklist
| # | Que verificar antes de asinar |
|---|---|
| □ | Ten contrato de encargado (DPA) que cumpre o art. 28.3 RGPD. |
| □ | Identifica ao responsable interno de protección de datos (nome ou función + correo de contacto). |
| □ | Publica a lista de subencargados e notifica cambios. |
| □ | Indica a ubicación dos servidores e, se hai transferencias internacionais, a base xurídica (decisión de adecuación, DPF, CCT). |
| □ | Describe as súas medidas de seguridade (cifrado, autenticación, accesos por rol, logs, copias de seguridade). |
| □ | Conta con certificacións recoñecidas ou informes equivalentes. |
| □ | Notifica brechas ao responsable sen demora indebida. |
| □ | Permite exportar os datos en formato útil ao final do contrato e só despois suprímeos. |
| □ | Non reutiliza os datos do restaurante para finalidades propias sen base xurídica adecuada e independente. |
| □ | Habilita unha canle de auditoría proporcionada e documentada. |
O TPV e o sistema de reservas son ferramentas críticas para a operativa diaria, pero tamén activos de información sensible. Elixir ben o provedor, asinar o contrato adecuado e ter clara a saída é o que converte a protección de datos en parte do oficio, e non nunha preocupación engadida.
"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®
Se tes un restaurante ou grupo de restauración e queres revisar a túa documentación de protección de datos, en Certix traballamos especificamente con hostalaría. Sen comerciais: desde o primeiro contacto, falarás cun especialista.
Guía de protección de datos para restaurantes
Este contido é meramente orientativo e divulgativo; non constitúe en ningún caso asesoramento xurídico especializado. A normativa autonómica sectorial pode ampliar ou modificar os prazos e requisitos da norma estatal. A aplicación da normativa a cada caso concreto require análise individualizado.