Contrato de Encargo del Tratamiento (DPA) — Agendia Citas

Versión: 0.1-borrador · Fecha: [FECHA] · Sustituye a: — · Idioma: ES

Partes

• Encargado del tratamiento: [RAZÓN SOCIAL] («Agendia»), NIF [NIF], [DOMICILIO], [EMAIL], en adelante el «Encargado».
• Responsable del tratamiento: el titular de la cuenta de salón que acepta este contrato en el onboarding o por escrito, en adelante el «Responsable».

Este DPA es accesorio a los Términos del Servicio de Agendia Citas y forma parte inseparable de ellos. En caso de conflicto sobre protección de datos, prevalece este DPA.

1. Objeto y ámbito

El Encargado trata datos personales por cuenta del Responsable exclusivamente para prestar el servicio de la plataforma Agendia Citas (gestión de reservas, agenda, clientas, comunicaciones, pagos de señal y funciones contratadas). El Encargado actúa solo conforme a las instrucciones documentadas del Responsable, siendo la configuración del servicio y el uso de la plataforma instrucción suficiente.

2. Objeto, duración, naturaleza y finalidad (art. 28.3)

3. Obligaciones del Encargado (art. 28.3)

El Encargado se obliga a:

a) Tratar los datos solo según instrucciones documentadas del Responsable, incluidas transferencias internacionales, salvo obligación legal (en cuyo caso informará antes, salvo prohibición legal).

b) Garantizar que las personas autorizadas a tratar los datos se han comprometido a confidencialidad (art. 28.3.b), vigente más allá del fin de la relación.

c) Adoptar las medidas de seguridad del art. 32 descritas en el Anexo II (TOMs).

d) Respetar el régimen de subencargados (§5).

e) Asistir al Responsable para atender las solicitudes de ejercicio de derechos de los interesados (§6).

f) Asistir al Responsable en el cumplimiento de los arts. 32-36 (seguridad, notificación de brechas, evaluaciones de impacto, consultas previas).

g) A elección del Responsable, suprimir o devolver los datos al finalizar la prestación (§9).

h) Poner a disposición del Responsable la información necesaria para demostrar el cumplimiento y permitir auditorías (§7).

i) Informar al Responsable de inmediato si, en su opinión, una instrucción infringe el RGPD u otra norma.

4. Obligaciones del Responsable

a) Garantizar que dispone de base jurídica válida (art. 6) para todos los tratamientos que realice a través de la plataforma, incluyendo la obtención del consentimiento informado del interesado cuando proceda y la información previa de los arts. 13-14. (Cláusula que blinda al Encargado — método §5.3.)

b) Facilitar sus propios textos legales (aviso legal, política de privacidad del salón) cuando publique la landing de dominio propio del módulo «Mi Web»; el Encargado solo provee la infraestructura.

c) No introducir en la plataforma categorías especiales del art. 9 ni datos ajenos a la finalidad.

d) Dar instrucciones lícitas y atender las solicitudes de derechos de sus clientas.

5. Subencargados (art. 28.2 y 28.4)

El Responsable autoriza con carácter general al Encargado a contratar los subencargados de la lista pública de subencargados ([URL PÚBLICA]). El Encargado:

• Impone a cada subencargado, por contrato, obligaciones de protección equivalentes a las de este DPA.
• Notificará cualquier alta o sustitución de subencargado con al menos 30 días naturales de antelación (por email al admin y/o aviso en el panel).
• El Responsable podrá oponerse motivadamente en 15 días naturales; si la oposición es razonable y no cabe alternativa, podrá rescindir sin penalización en los 30 días siguientes.
• Responde de la elección y supervisión razonable de los subencargados (due diligence).

Los subencargados opcionales (activados solo si el Responsable contrata el módulo correspondiente: Google Calendar, WhatsApp/SMS) solo tratan datos si el Responsable activa esa integración; el panel muestra «tus subencargados activos» según los módulos contratados.

6. Asistencia en derechos de los interesados

El Encargado asiste al Responsable, teniendo en cuenta la naturaleza del tratamiento y mediante medidas técnicas y organizativas apropiadas, para atender las solicitudes de acceso, rectificación, supresión, oposición, limitación y portabilidad. La plataforma ofrece funciones de exportación y borrado (ver Procedimiento ARCO+). Si un interesado se dirige directamente al Encargado, este trasladará la solicitud al Responsable sin atenderla por su cuenta (salvo instrucción).

7. Auditoría e inspección (art. 28.3.h)

El Encargado pone a disposición del Responsable el Anexo II (TOMs) y la información razonable para demostrar el cumplimiento. El Responsable podrá auditar (por sí o por un tercero independiente sujeto a confidencialidad) con preaviso razonable (p. ej. 30 días), sin perturbar indebidamente la operación y sin acceder a datos de otros responsables.

8. Acceso del personal del Encargado a los datos del Responsable

El personal del Encargado accede a los datos del Responsable solo para mantenimiento, soporte, depuración, gestión de incidentes o requerimiento legal, limitado al personal estrictamente necesario y formado en RGPD. Cada acceso queda registrado (quién, cuándo, tenant, motivo). El Responsable puede solicitar el registro de accesos. [FUTURO: función de impersonation auditada + panel «Accesos del proveedor» — método §6.B; hoy no existe función de impersonación del proveedor, control N/A. Si se implementa, se activa el régimen §6.B.]

9. Notificación de violaciones de seguridad (art. 33)

El Encargado notificará al Responsable sin dilación indebida y, como máximo, en 24 horas desde que tenga conocimiento de una violación de seguridad que afecte a sus datos, con el contenido mínimo del art. 33.3 (naturaleza, categorías y número aproximado de interesados y registros, consecuencias probables, medidas adoptadas, contacto). El protocolo operativo es el Plan de respuesta a brechas. La notificación no revela la identidad de otros responsables afectados (confidencialidad entre tenants).

10. Devolución y supresión al finalizar (art. 28.3.g)

Al finalizar la prestación, a elección del Responsable, el Encargado:

• Mantiene los datos disponibles para exportación durante 30 días naturales tras la baja.
• Transcurrido ese plazo, suprime físicamente los datos, salvo aquellos que deba conservar por obligación legal propia (p. ej. facturas de la suscripción).
• Los backups que contengan datos ya suprimidos se eliminan al vencer su plazo de retención; no se restauran salvo emergencia y, si se restauran, se reaplica la lista de borrados pendientes.

Detalle en la Política de retención.

11. Aislamiento entre responsables

El Encargado garantiza el aislamiento técnico entre los datos de los distintos responsables alojados en la misma infraestructura (arquitectura multi-tenant de esquema compartido con seguridad a nivel de fila). Detalle en el Anexo II.

12. Responsabilidad

Cada parte responde de los daños derivados del incumplimiento de sus obligaciones. [Límite de responsabilidad por incidente y agregado — VERIFICAR y cuantificar con asesor.] Nada en este DPA limita la responsabilidad que no pueda limitarse legalmente.

13. Transferencias internacionales

Cuando un subencargado implique transferencia fuera del EEE, se ampara en una garantía adecuada (decisión de adecuación / Data Privacy Framework / SCC), detallada en la lista de subencargados.

14. Duración, ley aplicable y jurisdicción

Este DPA rige mientras el Encargado trate datos por cuenta del Responsable. Se somete a la legislación española y de la UE y a los tribunales de [PLAZA].

ANEXO I — Descripción del tratamiento

(Resumen de §2, para adjuntar como anexo formal.)

• Responsable: [salón — se cumplimenta con los datos del tenant en el onboarding].
• Encargado: [RAZÓN SOCIAL].
• Finalidad: gestión de reservas y del salón mediante la plataforma Agendia Citas.
• Interesados: clientas del salón; personal del salón.
• Categorías de datos: identificativos y de contacto; datos de la reserva; preferencias de comunicación; datos opcionales (notas/etiquetas/foto). Sin categorías especiales del art. 9.
• Subencargados: los de la lista pública vigente.
• Duración: vigencia de la suscripción + periodo de exportación/borrado.

ANEXO II — Medidas Técnicas y Organizativas (TOMs)

Describe las medidas del art. 32 realmente implementadas en Agendia Citas. Es también la mejor herramienta comercial frente a revisiones de seguridad del cliente. (Verificado contra el código y las auditorías 01, 02, 05, 06 del hito 5.)

1. Aislamiento de datos entre responsables (multi-tenant)

• Capa 1 — filtro de aplicación: cada petición porta el identificador de organización; el backend fija el contexto de tenant por petición.
• Capa 2 — Row-Level Security de PostgreSQL: todas las tablas de dominio llevan políticas RLS con FORCE ROW LEVEL SECURITY; el rol de aplicación es NOSUPERUSER NOBYPASSRLS (no puede saltarse la RLS).
• Capa 3 — pruebas automatizadas: suite de aislamiento (L1/L2/L3) y pruebas e2e cross-tenant que fallan si hay fuga entre responsables (verificado en CI en cada cambio).
• Validación de pertenencia al tenant en las claves foráneas sensibles (la FK de PostgreSQL no aplica RLS por sí sola → guard explícito).

2. Cifrado en tránsito

• TLS (HTTPS) en todo el tráfico público, con HSTS, servido por Traefik con certificado Let's Encrypt.
• Cabeceras de seguridad: X-Content-Type-Options: nosniff, Referrer-Policy. [CSP preparada, pendiente de activación con verificación visual — TD-02.]

3. Cifrado en reposo

• Las credenciales de terceros (p. ej. tokens de Google Calendar) se almacenan cifradas (AES-256-GCM). [Mejora prevista: subclave por tenant + AAD — TD-01.]
• Contraseñas de usuario almacenadas con hash (algoritmo de Better Auth), nunca en claro.
• Backups con permisos restringidos; off-site cifrado (rclone a bucket UE) [pendiente de activar — TD-14].

4. Control de acceso

• Autenticación por Better Auth (sesión con cookie HttpOnly+Secure, primera parte).
• RBAC por roles dentro de cada salón (owner/admin/…); permisos verificados en cada ruta protegida.
• Claves de API por tenant (hash SHA-256 en BD, secreto mostrado una sola vez) para el conector, con RBAC del rol de la clave y revocación.

5. Registro y auditoría

• Registro de auditoría de autenticación (login OK/fallido, logout, cambio/restablecimiento de contraseña).
• last_used_at de claves de API. [Logging estructurado con redacción de PII — pendiente, TD-06.]

6. Resiliencia y continuidad

• Backups diarios de PostgreSQL (dump completo + globals) con verificación de restaurabilidad y retención de 14 días; restore probado a base scratch.
• Servicios como unidades systemd con reinicio automático; infraestructura en contenedores version-locked.
• Exposición de datastores restringida a loopback (PostgreSQL y Redis no alcanzables desde internet).

7. Minimización y separación

• Solo se tratan los datos necesarios para la reserva; consentimientos granulares y no premarcados; separación de comunicaciones transaccionales vs. marketing.

8. Gestión de subencargados

• Contratos art. 28 con cada subencargado; datos en la UE siempre que es posible; transferencias con garantías.

9. Personal

• Compromiso de confidencialidad; acceso mínimo necesario; formación en protección de datos. [Formalizar en contratos laborales — método §6.B.5.]

relleno de placeholders antes de hacerse firmar.*