Cuando aplica la gestion de encargados del tratamiento y que hacer despues

La gestion de encargados aplica cuando otra organizacion trata datos personales para tu empresa SaaS, o cuando tu empresa trata datos de clientes como encargado y usa otro tercero por debajo. La pregunta practica no es solo si existe un proveedor. Es si esa relacion implica datos personales tratados bajo instrucciones de otro y si puedes demostrar que esta controlada.

En SaaS, la respuesta suele ser si. Hosting, soporte, CRM, analitica de producto, billing, identidad, observabilidad, mensajeria de clientes, monitorizacion de seguridad, herramientas de AI, data warehouses y soporte externalizado pueden crear relaciones de encargado o subencargado.

El articulo 28 del RGPD exige que el responsable use solo encargados que ofrezcan garantias suficientes de medidas tecnicas y organizativas adecuadas. El tratamiento debe estar regulado por un contrato u otro acto juridico vinculante que describa materia, duracion, finalidad, tipos de datos, categorias de interesados y derechos y obligaciones del responsable.

En la practica, el contrato debe cubrir instrucciones documentadas, confidencialidad, seguridad, condiciones de subencargados, ayuda con derechos de interesados, eliminacion o devolucion al terminar el servicio, e informacion para demostrar cumplimiento y permitir auditorias.

Cuando aplica claramente

Aplica claramente cuando un tercero trata datos personales para una finalidad de producto o negocio definida y bajo tus instrucciones.

Ejemplos SaaS habituales: infraestructura cloud, helpdesk, chat, llamadas, email transaccional, product analytics, session replay, billing, pagos, identidad, logs, backups, respuesta a incidentes, CRM, marketing automation, herramientas AI para resumir o buscar contenido, y servicios externalizados de soporte u operaciones.

La misma empresa puede tener varias funciones. Un SaaS puede ser encargado para datos de clientes dentro del workspace, responsable para analitica web y datos de empleados, y responsable al revisar sus propios proveedores. Por eso importa mas la realidad del tratamiento que la etiqueta contractual.

Cuando no es tan obvio

Los casos dificiles suelen aparecer con acceso limitado, features opcionales, herramientas internas o vendors que dicen que no almacenan datos de clientes. No saltes la revision solo porque sean "solo metadatos". Los datos personales pueden aparecer en logs, adjuntos de soporte, identificadores, notas de cuenta, telemetria, prompts, exports y dashboards administrativos.

La guia del EDPB ayuda porque centra el analisis en quien determina las finalidades y los medios esenciales. Si el vendor usa los datos para mejora propia del producto, publicidad, benchmarking o entrenamiento de modelos, puede que no sea una relacion simple de encargado.

Que hacer primero

Empieza con un inventario rapido de relaciones que tocan datos personales. Para cada una, captura nombre legal del vendor, producto, owner de negocio, owner tecnico, workflow, rol, categorias de datos, personas afectadas, acceso a sistemas, DPA, subencargados, evidencia de seguridad, ubicacion de datos, transferencias, retencion, eliminacion, disclosure a clientes y proxima revision.

El registro no tiene que ser perfecto desde el primer dia. Tiene que ser util para que legal, seguridad, producto, procurement, customer success y audit owners respondan con los mismos hechos.

Integrarlo en el workflow operativo

La gestion de encargados falla cuando la revision empieza despues de que la herramienta ya esta en produccion. El trigger debe estar en procurement, lanzamiento de producto, security review y onboarding de vendors.

Un intake practico pregunta: que datos personales recibe o ve el vendor, que clientes o usuarios estan afectados, si hay subencargados, donde se alojan o acceden los datos, si el vendor usa datos para fines propios, y que evidencia existe sobre DPA, seguridad, transferencias y eliminacion.

Seguridad revisa medidas tecnicas y organizativas. Privacy o legal revisa rol, DPA, instrucciones, subencargados y transferencias. Procurement gestiona contrato y renovaciones. Producto o engineering controla limites de implementacion. Compliance confirma que la evidencia se pueda encontrar luego.

Subencargados antes de que pregunte el cliente

Los subencargados importan dos veces: tus vendors pueden usar sus propios subencargados y tus clientes suelen esperar una lista clara, notificaciones de cambio y un proceso de objecion alineado con el DPA.

El articulo 28 exige autorizacion previa especifica o general por escrito. En la practica necesitas una pagina o schedule estable de subencargados, un workflow de aprobacion y evidencia de que el cambio se reviso antes de incluirlo.

Evidencia que resiste revision

La evidencia util incluye DPA o terminos online, analisis de rol, cuestionario de seguridad, documentacion de seguridad, lista de subencargados, salvaguardia de transferencia, ticket de aprobacion, decision de riesgo residual, settings de retencion, procedimiento de eliminacion y disclosure a clientes.

Esto apoya la planificacion de GDPR, data protection by design and default, data minimisation y la idea de que GDPR no es solo cookie banners.

Ejemplo practico

Imagina que una empresa SaaS quiere anadir una herramienta AI que resume tickets de soporte. Puede recibir nombres, emails, account IDs, contenido de tickets, adjuntos y metadatos. El equipo decide primero si el vendor actua como encargado o usa el contenido para fines propios. Despues revisa DPA, instrucciones, seguridad, subencargados, hosting, transferencias, retencion, controles de entrenamiento y compromisos con clientes.

Si se aprueba, el registro documenta workflow, categorias de datos, owner, terminos, transferencia, configuracion, subencargados, ubicacion de evidencia y fecha de revision.

FAQ

Que deben entender los equipos?

Que aplica cuando terceros tratan datos personales por cuenta de la empresa o bajo su propia funcion de encargado. Debe producir owners, triggers, evidencia contractual, evidencia de seguridad, controles de subencargados y registros listos para auditoria.

Por que importa en la practica?

Porque los equipos SaaS dependen de terceros para operar producto y negocio. Sin control, DPAs, avisos de privacidad, cuestionarios de seguridad y respuestas de auditoria pueden separarse de la realidad.

Que documentar primero?

Empieza por relaciones que afectan datos de clientes, security reviews, transferencias, subencargados, AI o disclosures a clientes. Asigna owners, confirma el rol y recoge evidencia DPA y de seguridad.

Sources

• European Union, General Data Protection Regulation.
• European Data Protection Board, Guidelines 07/2020 on the concepts of controller and processor in the GDPR.
• Information Commissioner's Office, Contracts and liabilities between controllers and processors.
• European Commission, Standard contractual clauses for controllers and processors in the EU/EEA.