Contrato de encargado de tratamiento de datos (art. 28 RGPD)

🖨 Imprimir / guardar como PDF para firmar

Partes

• El RESPONSABLE del tratamiento: el despacho de administración de fincas que contrata Domunia (identificado por sus propios datos de alta: nombre del despacho, CIF y dirección registrados en su cuenta).
• El ENCARGADO del tratamiento: DATOS DE PRUEBA - Prestador de ejemplo (Domunia sin configurar) (NIF 00000000T, domicilio en Calle de Ejemplo 1, 38001 Santa Cruz de Tenerife (DATOS DE PRUEBA), contacto prestador.ejemplo@example.invalid) [DATOS DE PRUEBA: no identifican a ningún prestador real y este contrato no vincula a nadie mientras sigan puestos], como prestador del servicio Domunia.

1. Objeto

El responsable encarga al encargado el tratamiento de los datos personales necesarios para prestar el servicio Domunia: gestión de las comunidades de propietarios del responsable, sus viviendas, propietarios/vecinos, incidencias, suministros, economía (cuotas, gastos, presupuestos), juntas y actas, documentos, modelos tributarios, remesas SEPA y comunicaciones con los vecinos. El encargado trata estos datos únicamente por cuenta del responsable y siguiendo sus instrucciones documentadas (las que se derivan del uso normal de la aplicación por el propio responsable y su personal autorizado), y nunca para fines propios.

2. Duración

Este contrato está vigente mientras el responsable tenga contratado el servicio Domunia. Se extingue cuando el responsable causa baja del servicio, sin perjuicio de las obligaciones de confidencialidad y de las que subsistan tras la devolución o supresión de los datos (cláusula 9).

3. Naturaleza, finalidad y duración del tratamiento

Tratamiento total o parcialmente automatizado (alojamiento, consulta, almacenamiento, modificación, comunicación de datos según las funciones que use el responsable, y supresión) con la única finalidad de prestar las funciones de la aplicación Domunia contratadas por el responsable. La duración del tratamiento coincide con la del propio contrato de servicio.

4. Tipo de datos y categorías de interesados

El responsable decide qué datos introduce; en la práctica, la aplicación está preparada para tratar:

• Propietarios/vecinos de las comunidades: nombre, NIF, email, teléfono(s), IBAN de domiciliación, fecha del mandato SEPA, cargo en la junta, código de acceso al portal.
• Viviendas/plazas: identificador, coeficiente, email/código de contacto.
• Incidencias reportadas por los vecinos: texto libre, fotografías adjuntas, historial de gestión.
• Empleados de la comunidad (si los hay): nombre, NIF, puesto, salario, retención.
• Proveedores de la comunidad: nombre, contacto.
• Datos económicos: recibos, deudas, pagos.
• No se tratan categorías especiales de datos (salud, ideología, afiliación sindical…) como parte del diseño de la aplicación; si el responsable introduce ese tipo de información en un campo de texto libre (por ejemplo, en la descripción de una incidencia), es bajo su propia responsabilidad y debe evitarlo salvo necesidad justificada.

5. Obligaciones del encargado

1. Tratar los datos únicamente conforme a las instrucciones documentadas del responsable (el uso ordinario de la aplicación) y para la finalidad pactada; si considera que una instrucción infringe el RGPD u otra norma de protección de datos, lo informará al responsable.
2. Garantizar que las personas autorizadas a tratar los datos se han comprometido a guardar confidencialidad o están sujetas a una obligación legal de confidencialidad.
3. Adoptar las medidas de seguridad del artículo 32 RGPD (detalladas en la cláusula 6).
4. No recurrir a otro encargado (subencargado) sin la autorización previa, específica o general, del responsable (cláusula 7).
5. Asistir al responsable en la respuesta a solicitudes de derechos de los interesados y en el cumplimiento de sus obligaciones de seguridad, notificación de brechas y evaluaciones de impacto (cláusula 8).
6. Poner a disposición del responsable la información necesaria para demostrar el cumplimiento de estas obligaciones y permitir auditorías razonables.
7. Al finalizar el servicio, devolver o suprimir los datos según decida el responsable (cláusula 9).

6. Medidas de seguridad aplicadas (art. 32 RGPD)

Esta cláusula describe las medidas que la aplicación implementa realmente, no un catálogo genérico:

• Contraseñas: hash Argon2id (algoritmo recomendado, memory-hard); nunca se guardan en claro ni son reversibles.
• Cifrado en reposo: el IBAN y el NIF de los propietarios, las credenciales de acceso a los portales de proveedores de suministros y las copias recuperables de los códigos de acceso se cifran campo a campo con Fernet (AES-128 con verificación de integridad) antes de guardarse. En la base de datos no hay ningún número de cuenta legible; la clave de cifrado no está en la base de datos. Para poder buscar por NIF/IBAN y detectar altas duplicadas se guarda además una huella irreversible (HMAC-SHA256 con clave), que no permite reconstruir el dato.
• Exposición mínima en pantalla: en los listados del panel el IBAN se muestra enmascarado (sólo las últimas cuatro cifras); el número completo sólo se enseña cuando el administrador lo pide expresamente, y esa consulta queda registrada.
• Aislamiento multi-tenant: cada consulta a los datos de un despacho se filtra por su identificador en la capa de repositorios; un despacho no puede ver ni modificar los datos de otro.
• Sesiones: tokens firmados (JWT), en cookies de solo lectura por el servidor (httponly), transmitidas solo por HTTPS en producción, con caducidad de 24 horas. Al cambiar o restablecer una contraseña se invalidan todas las sesiones abiertas de esa cuenta.
• Gestión de la contraseña: cualquier usuario con contraseña (titular, colaborador, superadministrador y vecino del portal) puede cambiar la suya, pidiéndole la actual, y recuperarla si la olvida mediante un enlace por correo de un solo uso que caduca en 30 minutos, con límite de intentos y sin revelar si la cuenta existe.
• CSRF: todos los formularios de la aplicación llevan un token de un solo uso ligado a la sesión, para evitar que un tercero falsifique una petición en nombre del usuario.
• Fuerza bruta: los accesos (inicio de sesión del panel y del portal, formulario público de incidencias, asistentes de IA) tienen un límite de intentos por IP y por cuenta.
• Cifrado en tránsito: el acceso público se sirve por HTTPS.
• Copias de seguridad: copia diaria de la base de datos y de los documentos almacenados, con retención de las últimas copias. Limitación conocida: hoy esas copias se guardan en el mismo servidor que la aplicación; una copia adicional fuera del servidor está pendiente (ver docs/backup-y-restauracion.md).
• Registro de actividad: los accesos y errores quedan registrados con un identificador de petición y de despacho, sin registrar contraseñas ni secretos en claro; no hay hoy un plazo de purga automática definido para estos registros.

7. Subencargados autorizados

El responsable autoriza con carácter general el recurso a los siguientes subencargados, necesarios para el funcionamiento del servicio. El encargado informará al responsable de cualquier cambio (alta o sustitución) con antelación razonable, para que este pueda oponerse por motivos justificados:

Subencargado	Función	Ubicación	Cuándo interviene
Anthropic PBC	Asistentes de inteligencia artificial (redacción de incidencias, preguntas del administrador, sugerencias de resolución, extracción de facturas, borradores de actas y convocatorias)	Estados Unidos — transferencia amparada en cláusulas contractuales tipo de la Comisión Europea (art. 46 RGPD)	Solo si el titular de Domunia activa la clave de API de Anthropic; hasta entonces, ningún dato sale hacia este subencargado
Brevo (Sendinblue SAS)	Envío de correos electrónicos transaccionales (avisos, recordatorios de pago)	Francia — Unión Europea	Solo si el titular de Domunia tiene configurado el envío de correo
Redsys	Pasarela de pago con tarjeta/Bizum para que un vecino pague su recibo	España	Solo cuando un vecino elige pagar online un recibo
Servicios de notificaciones push de los navegadores (p. ej. Google, Mozilla, Apple)	Entrega técnica de los avisos push al dispositivo del vecino, conforme al estándar Web Push	Según el navegador del vecino	Solo si el vecino activa los avisos y el titular ha configurado el push
Proveedor de alojamiento del servidor	Infraestructura donde se ejecuta Domunia	España	Siempre (es donde vive la aplicación)

8. Asistencia al responsable

El encargado ayudará al responsable a atender las solicitudes de ejercicio de derechos de los interesados (acceso, rectificación, supresión, oposición, limitación, portabilidad) que le lleguen a través de la aplicación o que el responsable le traslade. En caso de una violación de la seguridad de los datos personales (una "brecha"), el encargado lo notificará al responsable sin dilación indebida y, en todo caso, en un plazo que permita al responsable cumplir su propio plazo de 72 horas ante la Agencia Española de Protección de Datos, con la información disponible en ese momento. El procedimiento interno de detección y notificación de brechas está en docs/notificacion-de-brechas.md.

9. Devolución o supresión de los datos

Al finalizar la prestación del servicio, el encargado pondrá los datos a disposición del responsable y los suprimirá, salvo que una norma exija su conservación. En la práctica, hoy esto se hace así:

• Devolución/exportación: el propio responsable puede exportar todos los datos de su cuenta en formato JSON desde /panel/cuenta/exportar, en cualquier momento, sin esperar a la baja.
• Supresión: el propio responsable puede borrar su cuenta y todos sus datos, de forma irreversible y en cascada (comunidades, propietarios, incidencias, recibos, documentos, actas), desde /panel/cuenta/borrar.

Nota para el titular: hoy estas dos acciones las ejecuta directamente el responsable desde la aplicación; no hay todavía un flujo separado de "solicitud de baja con confirmación" gestionado por el encargado. Si un responsable pide la supresión por otra vía (por ejemplo, por email, tras dejar de pagar la suscripción), el titular deberá ejecutar el borrado por él mientras no exista esa función.

10. Aceptación

Al contratar el servicio y aceptar estas condiciones (por ejemplo, al confirmar el alta por correo electrónico, o mediante firma de este documento impreso), el responsable acepta este contrato de encargado de tratamiento.

Nota para el titular: la aplicación no guarda hoy una fecha ni un registro de aceptación de este contrato en la ficha del despacho; si se quiere dejar constancia dentro de la propia aplicación (recomendable), haría falta una funcionalidad nueva para registrarlo, fuera del alcance de este cambio.

Por el RESPONSABLE Nombre y cargo: ______________________ Fecha: __________   Firma: __________

Por el ENCARGADO Nombre y cargo: ______________________ Fecha: __________   Firma: __________