Contrato de encargo del tratamiento (RGPD art. 28) — TimeViking
Última actualización: 6 de octubre de 2026
Este contrato forma parte de las condiciones generales. El cliente lo acepta al registrarse (junto con las condiciones y la declaración de privacidad) y de nuevo al pagar.
1. Funciones
- Responsable del tratamiento: el cliente (la empresa que utiliza el entorno).
- Encargado del tratamiento: Software Services BV, Meldertsestraat 8/4008, 3545 Halen, Bélgica, BE 0895.317.225.
2. Objeto, duración, naturaleza y finalidad
| Objeto | Registro de horas para el cliente, con sincronización opcional con el Odoo del cliente |
|---|---|
| Duración | Mientras dure la suscripción (o la prueba), más el periodo de solo lectura y la eliminación (§9) |
| Naturaleza | Almacenar, mostrar, calcular (informes, PDF mensual), sincronizar con Odoo, exportar |
| Finalidad | Únicamente prestar el servicio al cliente; ningún fin propio |
3. Categorías de interesados y de datos personales
- Interesados: los empleados y el personal del cliente que registran o gestionan horas; personas de contacto de los clientes del cliente (nombres de clientes en proyectos).
- Datos: nombre, correo electrónico, acceso; horas (fecha, hora, duración, descripción, proyecto, tarea); aprobaciones; el vínculo con un empleado de Odoo (ID, nombre, correo de trabajo); horario laboral y festivos; datos de ausencias (ver más abajo); ajustes; registro de auditoría (quién cambió qué).
- Datos de ausencias: el tipo de ausencia (p. ej., vacaciones anuales, enfermedad), el periodo (inicio y fin, días completos o medios días u horas), el estado de la solicitud (solicitada, aprobada, rechazada, retirada), quién decidió, una nota personal del solicitante o de quien decide, y el saldo (asignación, disfrutado, restante) por tipo.
- La enfermedad es un dato de salud (RGPD art. 9). El tipo «enfermedad» o un tipo similar muestra que alguien está enfermo. Nuestras medidas: no leemos ni guardamos el motivo que el empleado introduce en Odoo (
name/private_name); los compañeros solo ven «ausente» en el calendario del equipo y en el panel, sin el tipo; solo el propio empleado, su responsable y el administrador ven el tipo; un administrador puede marcar un tipo como «sensible», y entonces los compañeros nunca lo ven; para las ausencias, el registro de auditoría solo guarda el estado, quién decidió, las fechas y el tipo, nunca la nota ni un motivo de rechazo o retirada. El cliente evalúa por sí mismo la base jurídica del art. 9, apartado 2 (p. ej., 9.2.b, derecho laboral) y registra el tratamiento en su registro de actividades. - El cliente se asegura de que no se introduzcan detalles médicos en la nota libre ni en la descripción.
- No se prevén otras categorías especiales de datos (RGPD art. 9).
4. Obligaciones del encargado
El encargado:
- trata los datos solo siguiendo las instrucciones documentadas del cliente; las instrucciones son este contrato, las condiciones y los ajustes que el cliente elige en la aplicación (p. ej., la conexión con Odoo);
- garantiza que quienes tratan los datos están sujetos a confidencialidad;
- adopta medidas técnicas y organizativas apropiadas (anexo A);
- solo recurre a subencargados conforme al §6;
- ayuda al cliente con las solicitudes de los interesados (exportación en la aplicación, supresión, rectificación);
- ayuda con la seguridad, la notificación de violaciones y las evaluaciones de impacto relativas a la protección de datos, en la medida de lo razonable;
- elimina o devuelve los datos tras la finalización (§9);
- facilita la información necesaria para demostrar el cumplimiento y permite una auditoría (§8).
5. Violaciones de la seguridad de los datos personales
El encargado notifica una violación de la seguridad de los datos personales sin dilación indebida y, cuando sea posible, en un plazo de 48 horas desde su descubrimiento, a los administradores del entorno del cliente, con lo que se sepa (naturaleza, interesados, consecuencias, medidas). El cliente notifica a la autoridad de control y a los interesados.
6. Subencargados
El cliente otorga una autorización general para estos subencargados:
| Subencargado | Qué | Dónde |
|---|---|---|
| Nuestro proveedor de alojamiento | Servidores, bases de datos, copias de seguridad | Unión Europea |
Enviamos invitaciones y notificaciones con nuestro propio servidor de correo en nuestros servidores; no interviene ninguna otra parte.
No figuran en la lista porque no tratan los datos de horas: Mollie (solo datos de pago del propio cliente, para los que somos responsables), Google reCAPTCHA (solo en la página de registro y el formulario de contacto). El Odoo del cliente no es un subencargado: el cliente lo conecta por sí mismo.
Anunciamos un nuevo subencargado con 30 días de antelación; el cliente puede oponerse de forma motivada y, si no encontramos una solución, cancelar.
7. Transferencias fuera del EEE
Ninguna, salvo que el propio cliente conecte un Odoo fuera del EEE (en cuyo caso es el cliente quien da esa instrucción).
8. Auditoría
Previa solicitud, una vez al año, el encargado facilita una descripción de las medidas y los resultados de la última revisión de seguridad. Auditoría in situ con cita previa, a cargo del cliente y sujeta a confidencialidad.
9. Finalización
Los datos de ausencias (ausencias, reparto por día y saldo) siguen el mismo plazo de conservación que las horas: permanecen en el entorno mientras este exista, se incluyen en la exportación y se eliminan con él.
Tras el fin de la suscripción, el entorno permanece en solo lectura durante 60 días; el cliente puede exportarlo todo. Después, el encargado elimina la base de datos del entorno y los accesos y, tras 35 días, también las copias de seguridad (el periodo de rotación de las copias). El cliente puede hacer que se eliminen antes (en la aplicación).
10. Idioma y prevalencia
Este contrato existe en neerlandés, inglés, francés, alemán, español e italiano. En caso de diferencia entre las versiones, prevalece el texto en neerlandés. En caso de conflicto con las condiciones generales, prevalece este contrato en lo que respecta al tratamiento de datos personales.
Anexo A — Medidas
- Una base de datos separada y un usuario de base de datos separado por cliente; la aplicación no puede abrir la base de datos de otro cliente.
- Contraseñas con hash (scrypt/pbkdf2); claves de Odoo (de un usuario bot o personales) y el secreto del módulo cifrados (Fernet), nunca en los registros.
- Verificación en dos pasos disponible y obligatoria por entorno si se desea; nuestra propia administración siempre con verificación en dos pasos.
- Permisos por función y por empresa; un registro de auditoría de los cambios (para ausencias, sin nota ni motivo).
- Ausencias: los compañeros solo ven «ausente»; el tipo solo lo ven el empleado, su responsable y el administrador; no leemos el motivo desde Odoo.
- Para las ausencias, el bot en Odoo recibe la función Ausencias: Responsable, con la que ya puede ver todas las ausencias de las empresas en Odoo; el cliente asigna esa función por sí mismo y puede omitirla (las ausencias no funcionan entonces a través de la aplicación).
- Conexiones cifradas (TLS); las solicitudes entre el módulo y nosotros están firmadas (HMAC, hora y nonce).
- Límites en el inicio de sesión, el registro y la API; bloqueo tras fallos repetidos.
- Copias de seguridad diarias por base de datos, conservadas 35 días, restauración probada.
- Una revisión de seguridad antes del lanzamiento.