Data Processing Agreement para SaaS: las 9 cláusulas del Artículo 28 (guía 2026)

Si tu SaaS procesa datos personales por cuenta de clientes europeos, un Data Processing Agreement no es un "estaría bien tenerlo", es el contrato que el RGPD exige explícitamente. El Artículo 28 establece justo lo que ese contrato tiene que contener, y el coste de no acertar ha subido. El informe de DLA Piper publicado en enero de 2026 sitúa las multas acumuladas del RGPD por encima de 7.100 millones de euros desde que la norma entró en vigor, con una parte relevante del enforcement reciente atribuible a contratos de encargado inadecuados o inexistentes. Esta guía recorre los nueve elementos obligatorios de un DPA, dónde encajan las Cláusulas Contractuales Tipo y qué batallas de negociación vale la pena dar.

Qué es realmente un DPA, y qué no es

Un Data Processing Agreement es el contrato entre un responsable (tu cliente, el que decide qué hacer con los datos personales) y un encargado (tú, el SaaS que trata los datos por su cuenta). No sustituye al contrato de servicio subyacente. Lo complementa con cláusulas específicas del RGPD.

Un DPA tampoco es una política de privacidad. Una política de privacidad es lo que le cuentas al usuario final. Un DPA es lo que te comprometes con tu cliente empresarial. Los dos documentos se dirigen a audiencias distintas y tienen un peso jurídico distinto. Un SaaS que solo publica una política de privacidad y nunca ofrece un DPA está, en términos del RGPD, dejándose en el camino el artefacto contractual que exige el Artículo 28.

El marco de alcance: qué debe definir el contrato antes de las obligaciones

Antes de llegar a las ocho obligaciones del encargado, el Artículo 28(3) exige que el DPA defina el perímetro de la relación de tratamiento. Esta es la primera cláusula y no es negociable. El contrato debe establecer:

• Objeto del tratamiento. "Gestión de tickets de soporte" o "plataforma de analytics de marketing" es un nivel de especificidad utilizable.
• Duración del tratamiento. Normalmente vinculada al plazo de la suscripción subyacente más un período de retención para backups y logs.
• Naturaleza y finalidad del tratamiento. El "por qué" de lo que haces con los datos, no solo el "cómo".
• Tipo de datos personales y categorías de interesados. Direcciones de correo, IPs, telemetría de uso; empleados del responsable, usuarios finales del producto del responsable, contactos en un CRM.
• Obligaciones y derechos del responsable. Derecho a instruir, derecho a auditar, derecho a recuperar los datos al terminar.

Truco práctico: muchos DPAs de SaaS enlazan a un Anexo A donde se lista este alcance, así el cuerpo del contrato se mantiene estable mientras el anexo evoluciona con el producto.

Las ocho obligaciones del encargado bajo el Artículo 28(3)

Una vez definido el alcance, el Artículo 28(3) enumera ocho obligaciones específicas a las que el encargado se compromete. No son principios abstractos. Son cláusulas que tu DPA tiene que contener, prácticamente al pie de la letra.

(a) Tratar solo con instrucciones documentadas

El encargado "trata los datos personales únicamente siguiendo instrucciones documentadas del responsable". Esto incluye las transferencias fuera del EEE, que solo pueden ocurrir si el responsable las autoriza o lo exige la ley. En la práctica, esta cláusula es la que impide a un SaaS usar los datos del cliente para entrenar modelos compartidos o hacer cualquier cosa que el cliente no haya aprobado explícitamente.

(b) Confidencialidad de las personas autorizadas

Cualquier persona del lado del encargado que pueda acceder a los datos personales tiene que haberse comprometido a la confidencialidad o estar sujeta a una obligación legal de confidencialidad. Los contratos laborales estándar con cláusula de confidencialidad cubren esto, pero el DPA tiene que decirlo explícitamente.

(c) Medidas de seguridad del Artículo 32

El encargado debe adoptar todas las medidas exigidas por el Artículo 32, que es el artículo de seguridad del RGPD. Cifrado, integridad, resiliencia, pruebas regulares. El DPA no necesita listar cada control, pero sí comprometerse al estándar del Artículo 32. La mayoría de DPAs modernos referencian un Anexo de Seguridad que detalla los controles (SOC 2, ISO 27001, cifrado en reposo y en tránsito).

(d) Condiciones para subprocesadores

El encargado no puede contratar a otro encargado sin autorización previa específica o general por escrito. Con autorización general, el encargado se compromete a informar al responsable de los cambios previstos y a darle derecho a objetar. Con autorización específica, cada subprocesador queda nombrado por escrito antes de ser contratado. El DPA escoge un modelo y se queda con él.

(e) Asistir con los derechos de los interesados

El encargado asiste al responsable a responder a las solicitudes de los interesados bajo el Capítulo III del RGPD (acceso, rectificación, supresión, portabilidad, objeción, limitación). "Asiste" es la palabra clave: el responsable es quien cumple con el interesado, pero el encargado tiene que poner los datos a su disposición, entregarlos en un formato usable y actuar en un plazo razonable.

(f) Asistir con seguridad, notificación de brechas y EIPDs

El encargado asiste con las obligaciones de cumplimiento más amplias de los Artículos 32 a 36: mantener los datos seguros, notificar al responsable las brechas sin dilación indebida, contribuir a las evaluaciones de impacto cuando el responsable lo pida. El DPA suele fijar una ventana máxima de notificación de brechas: 24, 48 o 72 horas desde el conocimiento por parte del encargado.

(g) Suprimir o devolver los datos al final

Al terminar el servicio subyacente, el encargado o suprime todos los datos personales o se los devuelve al responsable, eliminando las copias salvo que la ley exija conservación. La mayoría de DPAs de SaaS conceden un breve período de gracia (30 a 90 días) para que el cliente exporte, y después procede a la supresión. Los backups tienen su propio plazo de retención que el DPA debe detallar.

(h) Poner información a disposición y permitir auditorías

El encargado "pone a disposición del responsable toda la información necesaria para demostrar el cumplimiento" y contribuye a las auditorías, incluidas las inspecciones. Los clientes enterprise ejercerán esta cláusula. La implementación más limpia es un Trust Center con informes SOC 2 vigentes, certificados ISO, resúmenes de pentest y un procedimiento de auditoría documentado para todo lo que no esté publicado.

Dónde encajan las Cláusulas Contractuales Tipo

El Artículo 28(7) da a la Comisión Europea la potestad de publicar Cláusulas Contractuales Tipo (CCT) para los contratos de encargado. En la práctica hay dos familias de CCT relevantes:

• CCT modulares de la UE (2021) para transferencias responsable-encargado fuera del EEE. Si tus servidores o tus subprocesadores están en EE. UU., India o cualquier país sin decisión de adecuación, tu DPA tiene que incorporar el módulo correcto.
• UK International Data Transfer Addendum, que se monta sobre las CCT de la UE para transferencias al Reino Unido tras el Brexit.

Las CCT no son opcionales y no puedes reescribirlas. Se incorporan por referencia, con los datos de las partes rellenando los anexos. El DPA especifica qué mecanismo de transferencia aplica (adecuación, CCT, BCR) para la ubicación de cada subprocesador.

Patrones de negociación que merece la pena conocer

La mayoría de DPAs de SaaS se le presentan al cliente como plantilla "tómalo o déjalo". Para la mayoría de clientes, eso funciona. Los clientes enterprise empujan de vuelta, y los puntos de fricción suelen aparecer en lugares predecibles.

• Derechos de auditoría: los clientes quieren auditorías presenciales ilimitadas; los encargados quieren revisión documental como máximo. El punto medio habitual es "revisión documental por defecto, auditoría presencial con preaviso razonable y en horario laboral si hay causa".
• Ventana de notificación de brechas: los clientes quieren 24 horas desde el incidente; los encargados quieren 72 horas desde la brecha confirmada. 48 horas desde la confirmación es un punto medio común.
• Ventana de objeción a subprocesadores: los clientes quieren 30 días; los encargados quieren 7. 14 días suele ser el acuerdo típico.
• Tope de responsabilidad: los encargados lo quieren ligado a las tarifas del servicio; los clientes lo quieren sin tope para infracciones de protección de datos. Excepciones específicas para multas del RGPD son un compromiso viable.

La AEPD española impuso más de 40 sanciones solo en 2024 donde la insuficiencia del DPA fue un factor contribuyente. El patrón en esas resoluciones es consistente: cláusulas ausentes, lenguaje vago sobre subprocesadores, sin derechos de auditoría. Negociar lejos tus obligaciones no es lo mismo que negociar la implementación. Las obligaciones se quedan igual.

Dónde encaja Termerly en tu flujo de DPA

Termerly es un host y editor para las páginas legales que tus clientes van a leer, incluido un DPA. No negocia el contrato por ti y no marca cambios en un MSA, pero gestiona las partes que se benefician del versionado y del alojamiento público.

• Puedes publicar tu DPA estándar en una URL permanente, enlazarlo desde la orden de compra y referenciarlo por versión en los acuerdos con clientes.
• Cada revisión crea un snapshot inmutable. Un cliente que firmó en mayo de 2024 puede probar qué versión del DPA estaba en vigor entonces abriendo el permalink de la versión que aceptó.
• El comparador muestra adiciones y eliminaciones entre dos versiones cualesquiera. Cuando actualizas la lista de subprocesadores o la ventana de notificación de brechas, el diff es lo que envías a los clientes enterprise en tu ciclo anual de cambios.
• Si operas varios productos SaaS bajo una misma empresa, cada proyecto guarda su propio DPA. A un cliente del Producto A no se le muestra el DPA del Producto B.

Conclusión

El Artículo 28 es una de las pocas partes del RGPD con una checklist clara. Define el alcance, comprométete con las ocho obligaciones del encargado, adjunta el módulo correcto de CCT para transferencias internacionales, y versiona el documento para poder mostrar qué estaba en vigor en cualquier fecha dada. Eso es el DPA operativo. Sáltate cualquiera de los nueve elementos y tu contrato queda incompleto; reescríbelos con carveouts y estás negociando lejos la exigibilidad.

Si todavía no tienes un DPA publicado, o el tuyo vive en un Google Doc sin historial de versiones, abre un proyecto gratis en Termerly y publica la primera versión esta semana. El enlace es lo que te pedirá un equipo de compras. El rastro de auditoría es lo que te protege cuando vuelvan al año siguiente.