Imagina esto: un proveedor de software que usas para gestionar nóminas sufre una brecha. Los datos de 200 empleados quedan expuestos (nombres, RUT, cuentas bancarias). La Agencia de Protección de Datos Personales te contacta y pide evidencia de que tenías controles sobre ese tratamiento delegado. Tu respuesta es un contrato de 14 páginas que nadie revisó desde que se firmó hace tres años. No hay registros de auditorías al proveedor. No hay evidencia de que los dispositivos que acceden a esos datos tengan cifrado o borrado remoto habilitado. No hay nada más que un PDF en una carpeta de SharePoint.
Esa es la realidad que la Ley 21.719 de Protección de Datos Personales viene a cambiar en Chile. La ley no solo exige que firmes un Data Processing Agreement (DPA) cuando delegas datos a terceros, exige que puedas demostrar que los controles pactados funcionan en la práctica. Y ahí es donde la mayoría de las organizaciones descubre que tiene un problema.
Un DPA perfecto no te salva si un laptop con esos datos desaparece sin control remoto.
Porque el contrato define las reglas. Pero el control operativo es lo que las hace reales. Sin visibilidad sobre los dispositivos que procesan datos, sin capacidad de actuar remotamente ante un incidente, sin registros que demuestren que tus medidas de seguridad existen fuera del papel, el DPA es una promesa vacía.
Este artículo te explica qué es un DPA, cuándo la ley chilena te obliga a tenerlo, qué cláusulas debe incluir y lo más importante, cómo respaldar cada una con controles técnicos que un auditor pueda verificar.
Qué es un Data Processing Agreement (DPA) y por qué importa bajo la Ley 21.719
Un Data Processing Agreement (DPA) es un contrato legalmente vinculante que establece las condiciones bajo las cuales una organización (el responsable) entrega datos personales a un tercero (el encargado o mandatario) para que los procese en su nombre. El DPA define qué datos se comparten, para qué fines, durante cuánto tiempo, y qué medidas de seguridad debe implementar el encargado.
En términos simples: si delegas el tratamiento de datos personales a alguien externo, necesitas un contrato que diga exactamente qué puede hacer con ellos, qué no puede hacer, y cómo los protege.
La Ley 21.719 introduce esta obligación de forma explícita. El artículo 15 bis establece que el tratamiento por parte de un mandatario o encargado debe regirse por un contrato que defina el objeto, la duración, la naturaleza del tratamiento, y las obligaciones de seguridad. No es una recomendación, es un requisito legal.
Pero aquí está el problema que pocas organizaciones anticipan: la ley no solo pide un contrato firmado. Pide que las medidas de seguridad sean reales, verificables, y proporcionales al riesgo. Si firmas un DPA que dice "el encargado implementará cifrado en todos los dispositivos" y luego no puedes demostrar que esos dispositivos están efectivamente cifrados, el contrato no te protege. Te incrimina.
Escenario: el auditor y la cláusula fantasma
Una empresa de servicios financieros contrata un proveedor de soporte técnico remoto. El DPA dice que todo acceso a datos de clientes se hará desde dispositivos cifrados y con autenticación de dos factores. Un auditor pide evidencia. El equipo de IT revisa y descubre que 12 de los 30 laptops del proveedor no tienen BitLocker activado y tres nunca se registraron en el inventario. La cláusula existía en el contrato. El control, no.
Quick win: Revisa el DPA de tu proveedor con mayor volumen de datos personales. Toma una cláusula de seguridad cualquiera (cifrado, acceso restringido, borrado al terminar el contrato) y pregúntate: ¿puedo demostrar esto con un registro, un log o un reporte? Si la respuesta es no, esa cláusula es decorativa.
Responsable vs. encargado: quién es quién en el DPA
Para que un DPA funcione, necesitas tener claro quién asume cada rol. La confusión entre responsable y encargado es una de las causas más comunes de incumplimiento, no por mala fe, sino porque nadie se tomó el tiempo de mapearlo.
El responsable de datos es la persona natural o jurídica que decide por qué y cómo se tratan los datos personales. En la práctica, eres tú: tu empresa recopila datos de clientes, empleados o usuarios, y decide para qué se usan. El responsable define los fines y los medios del tratamiento.
El encargado o mandatario es quien trata esos datos por cuenta del responsable, siguiendo sus instrucciones. Es tu proveedor de CRM, tu plataforma de email marketing, tu servicio de hosting, tu consultora de RRHH externa. El encargado no decide qué hacer con los datos — ejecuta lo que el responsable le indica.
La Ley 21.719 es clara: el responsable no se libera de sus obligaciones por haber delegado el tratamiento. Si tu proveedor comete un error, tu organización sigue siendo responsable ante el titular de los datos y ante la Agencia. El DPA existe precisamente para que puedas demostrar que hiciste tu parte que definiste instrucciones claras, exigiste medidas de seguridad, y supervisaste el cumplimiento.
Un punto que muchos equipos de IT pasan por alto: el encargado también puede tener dispositivos corporativos que acceden a tus datos. Y si esos dispositivos no están bajo ningún tipo de gestión o monitoreo, tienes un ángulo ciego que ningún contrato cubre.
Quick win: Haz una lista de todos los proveedores que acceden a datos personales de tu organización. Al lado de cada uno, anota: ¿tienen DPA firmado? ¿Sabes desde qué dispositivos acceden? ¿Puedes verificar sus medidas de seguridad? Si hay más de tres sin respuesta, tienes un gap de cumplimiento activo.
Cuándo es obligatorio firmar un DPA bajo la ley chilena
La regla es directa: si delegas tratamiento de datos personales a un tercero, necesitas un DPA. No hay zona gris.
Bajo la Ley 21.719, cualquier organización que transfiera datos personales a un mandatario o encargado para que los procese en su nombre está obligada a formalizar esa relación mediante un contrato. Esto aplica sin importar el tamaño de tu empresa, el volumen de datos, o el tipo de proveedor.
En la operación diaria, esto se traduce a situaciones que probablemente ya tienes:
- Software de gestión en la nube (ERP, CRM, HRIS): si tus datos de clientes o empleados están en Salesforce, HubSpot, BUK, o cualquier SaaS, necesitas DPA.
- Plataformas de email y comunicaciones: tu proveedor de email marketing procesa direcciones, nombres, historial de interacción. DPA.
- Soporte técnico externo: si un proveedor accede a equipos que contienen datos personales para dar soporte, DPA.
- Servicios de hosting y almacenamiento: si un proveedor aloja bases de datos con información personal, DPA.
- Pasarelas de pago: procesan datos financieros vinculados a personas identificables. DPA.
- Consultoras externas de RRHH, contabilidad, legal: si acceden a datos de empleados o clientes, DPA.
La prohibición que no puedes ignorar
La ley establece una restricción absoluta: el encargado no puede tratar los datos para un fin distinto al pactado, ni cederlos a terceros sin autorización expresa del responsable. Si tu proveedor de email marketing decide usar tu base de datos para entrenar un modelo de IA propio y no hay una cláusula que lo prohíba explícitamente, el problema es tuyo.
Escenario: el proveedor que usó datos para otro fin
Una clínica dental contrata una plataforma de agendamiento online. El DPA dice que la plataforma solo usará los datos de pacientes para gestionar citas. Seis meses después, los pacientes empiezan a recibir publicidad de productos dentales de terceros. La clínica descubre que la plataforma compartió su base con un partner comercial. La cláusula de finalidad existía, pero no había mecanismo de supervisión ni evidencia de auditorías periódicas al proveedor.
El contrato decía lo correcto. Pero sin control operativo, fue irrelevante.
Quick win: Revisa si tus DPAs actuales incluyen una cláusula de finalidad explícita que prohíba el uso de datos para fines no autorizados y la cesión a terceros sin tu consentimiento escrito. Si la cláusula no existe o es ambigua, ese es tu próximo ticket de compliance.
Cláusulas que todo DPA debe incluir y cómo respaldarlas con controles reales
Un DPA que solo cumple la forma legal pero no tiene respaldo operativo es un riesgo disfrazado de cumplimiento. Cada cláusula necesita un control técnico que la haga verificable.
Objeto y duración del tratamiento
El DPA debe definir con precisión: qué datos se comparten, para qué fin, y durante cuánto tiempo. Esta cláusula parece obvia, pero muchas organizaciones firman DPAs genéricos que dicen "datos necesarios para la prestación del servicio" sin especificar categorías, volúmenes ni plazos.
Lo que dice el contrato: el encargado tratará [datos específicos] para [fin específico] durante [período definido].
Lo que necesitas operativamente: un inventario actualizado de qué datos maneja cada proveedor, en qué dispositivos, y desde cuándo. Si no puedes responder "qué datos tiene el proveedor X en este momento", la cláusula de objeto es genérica y el control es inexistente.
Medidas de seguridad
Esta es la cláusula donde más organizaciones fallan. El DPA dice "el encargado implementará medidas de seguridad apropiadas". Pero apropiadas no significa nada si no puedes verificarlo.
La Ley 21.719 exige medidas técnicas y organizativas que garanticen confidencialidad, integridad y disponibilidad. Traducido a IT, esto significa:
- Cifrado de datos en reposo y en tránsito
- Control de acceso basado en roles
- Registros de acceso y auditoría
- Capacidad de borrado remoto en caso de incidente
- Gestión de dispositivos que acceden a los datos
Lo que necesitas operativamente: evidencia. Logs de cifrado, reportes de inventario de dispositivos, registros de borrado remoto, historial de accesos. Un auditor no va a leer tu DPA y asumir que se cumple — va a pedir pruebas.
Aquí es donde los dispositivos entran al juego. Si un proveedor accede a tus datos desde laptops que no están en ningún sistema de gestión, no tienes forma de verificar cifrado, no puedes forzar un borrado remoto si se pierde un equipo, y no tienes registro de dónde están esos dispositivos. La cláusula de seguridad del DPA queda hueca.
Subencargados
Tu proveedor puede subcontratar partes del servicio. El DPA debe definir si esto está permitido, bajo qué condiciones, y con qué obligaciones. La Ley 21.719 exige que el mandatario obtenga autorización del responsable antes de delegar a un subencargado, y que este quede sujeto a las mismas obligaciones de seguridad.
Lo que necesitas operativamente: una cláusula clara que exija notificación previa antes de subcontratar, y que imponga al subencargado las mismas medidas de seguridad del DPA original. Además, necesitas capacidad de verificar que esas medidas se cumplen en toda la cadena, no solo con tu proveedor directo.
Fin del servicio: devolución o eliminación de datos
Cuando el contrato termina, ¿qué pasa con los datos? El DPA debe especificar si el encargado devuelve los datos, los elimina, o ambas cosas. Y debe definir plazos y mecanismos concretos.
Lo que necesitas operativamente: confirmación verificable de que los datos fueron eliminados. No basta un correo que diga "confirmamos que borramos todo". Necesitas evidencia técnica: logs de eliminación, certificación de borrado de dispositivos, confirmación de que no quedan copias en backups del proveedor.
Escenario: el término de contrato sin limpieza
Una empresa cambia de proveedor de hosting. El contrato anterior tenía un DPA que decía "al terminar el servicio, el proveedor eliminará todos los datos en un plazo de 30 días". Dos meses después del cambio, el equipo de IT descubre que el antiguo proveedor aún tiene una copia completa de la base de datos en un servidor de staging que nadie apagó. No hay log de eliminación, no hay certificación, y el dispositivo físico donde están esos datos no tiene ningún control de acceso actualizado.
El contrato decía lo correcto. Pero nadie verificó que se ejecutara.
Quick win: Para tus proveedores actuales con DPA vigente, verifica si la cláusula de fin de servicio define un plazo concreto de eliminación y un mecanismo verificable (log, certificación, confirmación técnica). Si dice algo como "el proveedor eliminará los datos oportunamente", eso es insuficiente.
El dispositivo como eslabón físico del DPA
Hay un ángulo que la mayoría de los DPAs ignora por completo: los dispositivos desde los cuales se accede a los datos delegados.
Puedes tener el DPA más completo del mercado. Cláusulas de finalidad, medidas de seguridad, restricciones de subencargados, protocolo de terminación. Todo perfecto en papel. Pero si un laptop del equipo del proveedor o del tuyo, que contiene datos personales se pierde en un taxi, y no tienes capacidad de localizarlo, bloquearlo o borrar la información remotamente, toda esa estructura contractual se desmorona en un incidente.
Un DPA sin control sobre los endpoints es cumplimiento a medias.
La Ley 21.719 exige que las medidas de seguridad sean "técnicas y organizativas". Los dispositivos son la capa técnica más directa. Si no puedes demostrar que los equipos que procesan datos personales están cifrados, monitoreados y con capacidad de respuesta remota, te falta la mitad de la ecuación.
Esto no es solo un problema de tu organización. También aplica a tus proveedores. Si firmas un DPA que exige medidas de seguridad sobre dispositivos pero no tienes forma de verificar que el proveedor realmente las implementa, la cláusula existe solo en el contrato.
Los equipos de IT que integran gestión de dispositivos en su estrategia de cumplimiento tienen una ventaja concreta: pueden generar evidencia operativa de cada control. Cifrado habilitado, último check-in, historial de ubicaciones, acciones remotas ejecutadas. Eso es lo que un auditor necesita ver — no un párrafo en un PDF.
Quick win: Haz un cruce entre tu lista de proveedores con DPA y tu inventario de dispositivos. Identifica: ¿hay laptops o celulares que acceden a datos delegados y no están en tu sistema de gestión? Si la respuesta es sí, ahí tienes un riesgo que el DPA no cubre.
Cómo respaldar tu DPA con control operativo sobre dispositivos
Cuando un dispositivo con datos personales delegados se pierde o es robado, la secuencia de respuesta es: bloquear, borrar, documentar. En ese orden. Cada paso necesita herramientas que funcionen en tiempo real.
Plataformas de seguridad y gestión de dispositivos permiten ejecutar esta secuencia desde un solo lugar. Prey, por ejemplo, opera como la capa de control físico que respalda las cláusulas técnicas de un DPA:
- Bloqueo remoto del dispositivo. No es solo un bloqueo de pantalla, es un bloqueo a nivel de sistema operativo que impide el acceso al equipo completo. Si un laptop con datos de clientes desaparece un viernes a las 7 PM, puedes bloquearlo desde el dashboard antes de que alguien intente acceder.
- Borrado remoto y factory reset. Si determinas que el dispositivo no se va a recuperar, puedes ejecutar un borrado remoto que elimina todos los datos del equipo. Prey permite factory reset completo en Windows, macOS y dispositivos móviles , una capacidad que pocas herramientas del mercado ofrecen.
- Evidencia documentada. El registro de cada acción, bloqueo ejecutado, borrado completado, ubicación del dispositivo al momento del incidente queda en el audit log. Esa evidencia es exactamente lo que necesitas cuando la Agencia de Protección de Datos pide demostrar que actuaste ante un incidente.
Además, herramientas como Prey generan inventario de hardware y software, verifican estado de cifrado, y registran historial de ubicaciones. Todo esto alimenta la evidencia operativa que un DPA requiere pero que sin control sobre los endpoints es imposible de producir.
En entornos con flotas distribuidas( equipos en oficina, casa, terreno) y múltiples sistemas operativos, la visibilidad centralizada sobre dispositivos no es un lujo. Es el mecanismo que convierte cláusulas contractuales en controles verificables.
Para un modelo de cumplimiento integral, el control sobre dispositivos es el puente entre lo que el DPA promete y lo que tu equipo realmente puede ejecutar.
Consecuencias de no tener DPA: multas, responsabilidad y reputación
La Ley 21.719 no es solo declarativa. La futura Agencia de Protección de Datos Personales tendrá facultades sancionatorias reales.
Las infracciones graves — como no tener contrato con un mandatario que trata datos, o no implementar medidas de seguridad apropiadas pueden resultar en multas de hasta 20.000 UTM (aproximadamente $1.300 millones de pesos chilenos al valor actual). Pero las multas no son el único riesgo.
El daño reputacional es más difícil de cuantificar pero igual de real. Una brecha que expone datos de clientes porque no había DPA, o porque había un DPA sin controles operativos. destruye confianza. Y en mercados donde la regulación es nueva, los primeros casos van a sentar precedente.
La ley también establece el deber de notificar brechas a la Agencia y a los titulares afectados cuando un incidente compromete datos personales. Si la brecha ocurre en el ámbito de un encargado que no tenía DPA o que no cumplía con las medidas pactadas, el responsable no puede trasladar la culpa. La responsabilidad sigue siendo tuya.
Lo que cambia la ecuación es la capacidad de demostrar diligencia. Si puedes mostrar que tenías un DPA vigente, que las medidas de seguridad estaban implementadas y verificadas, que tenías control sobre los dispositivos que procesaban esos datos, y que actuaste inmediatamente ante el incidente, la posición ante la Agencia es radicalmente diferente.
Quick win: Prepara un documento interno de "evidencia de diligencia" para tus tres proveedores principales. Incluye: DPA firmado (fecha), última verificación de medidas de seguridad (fecha), herramienta de gestión de dispositivos activa (nombre, cobertura), y último reporte de inventario. Si no puedes llenar alguno de estos campos, sabes dónde está tu próximo gap.
Cómo implementar un DPA que funcione: la checklist operativa
No se trata de tener un DPA perfecto. Se trata de tener un DPA que refleje lo que realmente haces.
Estas son las acciones concretas para pasar de cumplimiento de papel a cumplimiento operativo:
- Mapea tus encargados. Lista todos los proveedores que acceden a datos personales. Incluye SaaS, hosting, soporte, consultores, pasarelas de pago.
- Clasifica por riesgo. No todos los proveedores manejan el mismo volumen o sensibilidad de datos. Prioriza los que acceden a datos sensibles (salud, financieros, laborales) o los que manejan mayores volúmenes.
- Revisa o crea los DPAs. Para cada proveedor prioritario, verifica si existe un DPA. Si no, créalo. Si existe, revísalo contra las exigencias de la Ley 21.719: objeto, duración, medidas de seguridad, subencargados, terminación.
- Exige evidencia, no declaraciones. Cada medida de seguridad pactada debe tener un mecanismo de verificación. ¿Cifrado? Pide reporte. ¿Control de acceso? Pide log. ¿Gestión de dispositivos? Pide inventario.
- Integra el control de dispositivos. Si tu proveedor — o tu propio equipo — accede a datos delegados desde laptops o móviles, esos dispositivos deben estar gestionados. Cifrado verificado, capacidad de borrado remoto, inventario actualizado. Plataformas de MDM y compliance hacen esta verificación automática.
- Programa revisiones periódicas. Un DPA firmado en 2024 puede quedar obsoleto en 2025 si el proveedor cambió de infraestructura, agregó subencargados, o modificó sus medidas de seguridad. Define frecuencia de revisión (anual como mínimo).
- Documenta todo. Cada revisión, cada verificación, cada incidente y su respuesta. Esta documentación es tu evidencia de diligencia si alguna vez necesitas responder ante la Agencia.
Quick win: Bloquea 2 horas esta semana para completar los pasos 1 y 2. Con un spreadsheet básico puedes mapear tus proveedores, clasificar riesgo, y detectar cuáles no tienen DPA. Ese documento es el punto de partida de toda tu estrategia de cumplimiento con encargados.
Conclusión
El Data Processing Agreement no es un trámite legal que firmas y archivas. Es un compromiso operativo que tu equipo de IT necesita respaldar todos los días con controles reales.
La Ley 21.719 no te pide solo que tengas un contrato con tus proveedores. Te pide que las medidas de seguridad pactadas sean verificables, que los datos estén protegidos en cada dispositivo que los toca, y que ante un incidente puedas demostrar que actuaste con diligencia.
Un DPA sin control técnico es una promesa vacía. El contrato define las reglas, pero son tus herramientas de gestión de dispositivos, tu capacidad de borrado remoto, tu inventario actualizado y tu historial de acciones los que convierten esas reglas en evidencia.
Empieza por lo concreto: identifica tus proveedores con mayor riesgo, revisa si tienes DPAs vigentes, y verifica que cada cláusula de seguridad tenga un control operativo detrás. Eso no un PDF de 14 páginas es lo que te protege cuando la Agencia llama.
Preguntas frecuentes
¿Un DPA es lo mismo que una política de privacidad?
No. Una política de privacidad es el documento que informa a los titulares (clientes, usuarios, empleados) sobre cómo tu organización recopila, usa y protege sus datos personales. Es pública y orientada al titular. Un DPA es un contrato privado entre tu organización (responsable) y un proveedor (encargado) que regula cómo ese proveedor trata los datos que le delegas. Son documentos complementarios, no intercambiables.
¿Qué hago si mi proveedor no quiere firmar un DPA?
Es una señal de alerta seria. Bajo la Ley 21.719, delegar tratamiento de datos sin un contrato formalizado es un incumplimiento. Si tu proveedor se niega a firmar un DPA, evalúa si el riesgo de seguir trabajando con él es aceptable. En muchos casos, la negativa a firmar indica que el proveedor no tiene las medidas de seguridad que el contrato exigiría y eso es exactamente el riesgo que el DPA busca gestionar.
¿El DPA aplica para proveedores fuera de Chile?
Sí. Si tu organización está sujeta a la Ley 21.719 y delegas tratamiento de datos personales a un proveedor ubicado en otro país, necesitas un DPA que cumpla con los requisitos de la ley chilena. Además, si los datos se transfieren fuera del territorio, aplican las reglas de transferencia internacional de datos. La ubicación del proveedor no elimina tu obligación como responsable.
¿Cada cuánto debo renovar o revisar el DPA?
La ley no define una frecuencia específica, pero la práctica recomendada es revisar el DPA al menos una vez al año, y siempre que haya cambios significativos: nuevo subencargado, cambio de infraestructura del proveedor, modificación en los tipos de datos tratados, o cambios regulatorios. Un DPA desactualizado es casi tan riesgoso como no tener uno.
¿Qué multas aplican por no tener DPA en Chile?
La Ley 21.719 clasifica las infracciones en leves, graves y gravísimas. No tener un contrato formalizado con un mandatario que trata datos puede considerarse una infracción grave. Las multas por infracciones graves pueden llegar hasta 20.000 UTM. Pero más allá de la multa, la ausencia de DPA dificulta demostrar diligencia ante cualquier incidente de seguridad que involucre datos delegados.
¿Necesito un DPA si el proveedor solo almacena datos sin procesarlos?
Sí. Bajo la Ley 21.719, el almacenamiento se considera una forma de tratamiento de datos personales. Incluso si el proveedor solo guarda información sin acceder a ella o modificarla, la relación de delegación existe y debe estar regulada por un contrato.
