Checklist de gestion de encargados del tratamiento para founders y responsables de compliance

La gestion de encargados funciona mejor como una checklist operativa, no como una interpretacion juridica aislada. Un equipo SaaS debe poder identificar cuando un proveedor trata datos personales por su cuenta, confirmar el rol, revisar contrato y evidencia de seguridad, aprobar subencargados, registrar salvaguardas de transferencia cuando correspondan y mantener la evidencia actualizada.

El objetivo es que cada relacion tenga propietario, finalidad, decision documentada, paquete de evidencia y disparador de revision. Si el equipo no puede responder quien es responsable, que datos se tratan, que instrucciones aplican y donde esta la evidencia, el proceso todavia no esta operativo.

1. Confirmar si aplica

Aplica cuando un tercero trata datos personales por cuenta de la organizacion y siguiendo sus instrucciones. Tambien aplica cuando la empresa SaaS actua como encargada para datos de clientes y utiliza subencargados.

Pregunta si el proveedor recibe, almacena, accede, transmite, analiza o genera datos personales; si actua siguiendo instrucciones documentadas; si decide finalidades propias; si intervienen datos de clientes, usuarios, empleados, soporte, logs, facturacion o metadatos; y si usa subencargados.

La guia del EDPB sobre responsables y encargados es clave porque el rol depende del tratamiento real, no solo de la etiqueta contractual. Si hay duda, registra la incertidumbre y elevala antes de que fluyan datos.

2. Crear el registro basico

Cada encargado aprobado debe tener un registro util. Incluye nombre legal, producto, propietario interno, finalidad, evaluacion de rol, categorias de datos, categorias de interesados, sistemas conectados, ubicacion de datos, ruta de transferencia, estado del DPA, revision de seguridad, subencargados, retencion, eliminacion, divulgacion a clientes, ultima revision y siguiente disparador.

Ese registro es el mapa operativo para legal, seguridad, producto, compras, ventas y compliance. Evita listas contradictorias y reduce trabajo repetido en revisiones de clientes.

3. Revisar los requisitos de articulo 28

El contrato u otro acto vinculante debe describir materia y duracion, naturaleza y finalidad, tipos de datos, categorias de interesados y obligaciones y derechos del responsable. Tambien debe cubrir instrucciones documentadas, confidencialidad, seguridad, asistencia, supresion o devolucion, informacion para demostrar cumplimiento, auditorias y condiciones para subencargados.

Las clausulas contractuales tipo de la Comision Europea para responsables y encargados pueden servir como referencia estructurada, aunque no sustituyen la revision de la relacion concreta.

4. Revisar garantias y evidencia

Las garantias suficientes no se prueban solo con un DPA. Revisa controles de acceso, autenticacion, logs, cifrado, separacion de clientes, gestion de incidentes, vulnerabilidades, certificaciones, retencion, borrado, acceso de soporte y uso de datos para entrenamiento de IA o mejora de producto.

La profundidad debe ser proporcional. Un proveedor con contenido de clientes, datos de produccion o logs sensibles requiere mas revision que una herramienta interna de bajo riesgo.

5. Controlar subencargados

Pregunta que subencargados pueden acceder a los datos, que servicio prestan, donde ocurre el tratamiento, si asumen obligaciones equivalentes, que autorizacion exige el DPA, como se notifican cambios a clientes, quien gestiona objeciones y cuando puede engineering activar una nueva dependencia.

La lista interna debe coincidir con la pagina publica de subencargados o el anexo del DPA. Las diferencias erosionan la confianza.

6. Definir transferencias, evidencia y revisiones

Registra donde se alojan los datos, desde donde se puede acceder y que mecanismo de transferencia aplica. No adivines. Si la ruta no esta clara, no deberia comenzar el tratamiento hasta completar la evaluacion.

Guarda DPA, analisis de rol, revision de seguridad, lista de subencargados, mecanismo de transferencia, condiciones de configuracion, ticket de aprobacion, decision de riesgo residual y siguiente fecha de revision. Activa una nueva revision ante nuevas funcionalidades, subencargados, regiones, funciones de IA, renovaciones, compromisos con clientes o evidencia obsoleta.

FAQ

Cual es el proposito practico?

Hacer controlable el tratamiento por terceros: saber que proveedores tratan datos, que instrucciones aplican, que evidencia respalda la decision y cuando se revisa de nuevo.

Cuando aplica a equipos SaaS?

Cuando un proveedor o subencargado trata datos personales por cuenta del equipo, o cuando la empresa SaaS usa subencargados para datos de clientes.

Que debe documentarse primero?

Empieza por el registro de procesadores que tocan datos de clientes o produccion: owner, finalidad, rol, datos, DPA, seguridad, subencargados, transferencia, decision y siguiente disparador.

Fuentes

• 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.