DPA y RGPD: qué es un contrato de encargado de tratamiento y cuándo lo necesita tu startup

Usas HubSpot, Brevo, Stripe, Google Workspace, Notion y cinco herramientas más. Todas ellas procesan datos de tus clientes o empleados. ¿Tienes un acuerdo firmado con cada una de ellas? Si la respuesta es no —o no estás seguro— estás incumpliendo el Reglamento General de Protección de Datos (RGPD) desde el primer día. Este artículo explica qué es un DPA, cuándo lo necesitas, qué debe incluir y cuáles son los errores más comunes en startups.

¿Con qué proveedores necesito un DPA? Guía rápida

Qué es un DPA y por qué el RGPD te obliga a tenerlo

El RGPD (Reglamento (UE) 2016/679) establece en su artículo 28 que cuando una organización —el Responsable del Tratamiento— encarga a un tercero que trate datos personales en su nombre, debe suscribir un contrato o acto jurídico vinculante con ese tercero: el Acuerdo de Encargado del Tratamiento, conocido en inglés como DPA (Data Processing Agreement) y en español como APA o AET.

Este acuerdo no es una formalidad burocrática. Es el mecanismo que garantiza que tu proveedor trata los datos de tus usuarios siguiendo tus instrucciones —no las suyas propias— y que asume las responsabilidades y medidas de seguridad que el RGPD exige.

Responsable vs Encargado: la distinción que lo cambia todo

Entender esta distinción es fundamental, porque determina quién responde ante el usuario y ante la AEPD (Agencia Española de Protección de Datos).

La clave está en quién determina los fines y los medios del tratamiento. Si el proveedor trata los datos siguiendo tus instrucciones —sin decidir por sí mismo para qué los usa—, normalmente actúa como Encargado (art. 4.8 RGPD) y el instrumento adecuado es el contrato de encargado de tratamiento (art. 28 RGPD). Si, en cambio, el proveedor decide de forma autónoma los fines del tratamiento, ya no es tu Encargado: puede ser un Responsable independiente —con quien no necesitas un DPA sino una relación jurídica distinta— o un Corresponsable, para lo que el RGPD prevé un acuerdo específico (art. 26 RGPD). Esto ocurre, por ejemplo, con plataformas publicitarias que usan los datos que les envías para entrenar sus propios modelos o para optimizar sus redes de anuncios con fines propios.

¿Con qué herramientas necesitas un DPA?

La regla es simple: cualquier tercero externo que acceda o procese datos personales de tus usuarios, clientes o empleados en tu nombre. En la práctica, esto cubre casi todo tu stack:

No necesitas DPA con un proveedor que no accede a datos personales —un diseñador freelance que solo entrega archivos de diseño, por ejemplo. Sí lo necesitas si ese diseñador, para hacer su trabajo, accede a tu CRM o a fotos de usuarios.

Las 8 cláusulas que todo DPA debe incluir (art. 28.3 RGPD)

El artículo 28.3 RGPD establece el contenido mínimo obligatorio de cualquier DPA. Si el acuerdo que tienes con un proveedor no incluye estas cláusulas, no es válido a efectos del RGPD:

El DPA del proveedor: ¿firmo y listo?

La mayoría de grandes proveedores SaaS —Google, Microsoft, HubSpot, Stripe, Brevo— tienen su propio DPA que puedes aceptar desde el panel de administración. Esto es conveniente, pero hay que tener en cuenta varias cosas:

Lo que suelen hacer bien los grandes proveedores:

• Incluyen las 8 cláusulas del art. 28.3 RGPD.
• Incorporan las Cláusulas Contractuales Tipo (SCCs) de la Decisión (UE) 2021/914 para transferencias internacionales.
• Publican listas de subencargados actualizadas.
• Tienen certificaciones de seguridad auditables (ISO 27001, SOC 2 Type II).

Lo que puede fallar con proveedores más pequeños:

• DPAs incompletos que no cubren las cláusulas del art. 28.3 RGPD.
• Ausencia de mecanismo de transferencia internacional (sin SCCs, sin certificación en EU-US DPF).
• Listas de subencargados vagas o inexistentes.
• Sin procedimiento claro de notificación de brechas de seguridad.
• Cláusulas de limitación de responsabilidad que contradicen tu exposición real bajo el RGPD.

Aunque el DPA sea estándar y no puedas negociarlo, verifica que cubre:

• El servicio concreto que contratas (algunos DPAs son genéricos y no describen las actividades de tratamiento).
• La lista de subencargados y el mecanismo de notificación de cambios.
• El mecanismo de transferencia internacional aplicable (SCCs, DPF o decisión de adecuación).
• Las medidas de seguridad técnicas y organizativas (art. 32 RGPD).
• El plazo de conservación de datos y el proceso de eliminación o devolución al finalizar el servicio.
• La asistencia para responder solicitudes de acceso, rectificación, supresión y portabilidad de tus usuarios.

Subencargados: la cadena que muchos olvidan

Cuando contratas a HubSpot, HubSpot a su vez usa AWS, Twilio, y decenas de otros proveedores que acceden a esos datos. Cada uno de ellos es un subencargado. El art. 28.4 RGPD establece que el encargado solo puede recurrir a subencargados con tu autorización previa, y debe imponerles las mismas obligaciones que tú le impones a él.

En la práctica, esto funciona mediante autorización general: el DPA indica que el proveedor puede usar subencargados de una lista publicada, y tú tienes derecho a oponerte si incorporan uno nuevo con el que no estás de acuerdo. Verifica que el acuerdo de encargado de tratamiento especifique: (1) si el encargado puede subcontratar y bajo qué condiciones; (2) cómo y con cuánta antelación te notifican la incorporación de nuevos subencargados; (3) el plazo y el procedimiento para ejercer tu derecho de oposición; y (4) que los subencargados asumen exactamente las mismas obligaciones que el encargado principal (art. 28.4 RGPD). Si el DPA no regula estos puntos, tienes un punto ciego relevante.

Transferencias internacionales: el riesgo de los SaaS americanos

La mayoría de los SaaS más usados por startups son empresas americanas: Google, Microsoft, Slack, Notion, Stripe, HubSpot, Intercom, Zoom, AWS, etc. Cuando datos de tus usuarios europeos viajan a servidores en EE.UU. (o son accesibles desde allí), estamos ante una transferencia internacional de datos sujeta a los arts. 44-49 RGPD.

No toda transferencia a un proveedor extranjero requiere automáticamente SCCs. El orden correcto para legalizar una transferencia internacional es:

1. Comprobar si existe decisión de adecuación para el país de destino (art. 45 RGPD). La Comisión Europea ha reconocido como adecuados países como Suiza, Japón, Canadá o el Reino Unido. Para EE.UU. no existe decisión de adecuación general.
2. EU-US Data Privacy Framework (DPF) — Decisión (UE) 2023/1795: si el proveedor americano está certificado en el DPF, las transferencias son legales sin necesidad de SCCs adicionales. Atención: la validez del DPF está bajo escrutinio político y judicial; conviene monitorizar su evolución.
3. Cláusulas Contractuales Tipo (SCCs) — Decisión (UE) 2021/914: cuando no aplican los mecanismos anteriores, las SCCs son el instrumento más habitual. Deben ir acompañadas de una Transfer Impact Assessment (TIA) que evalúe si la legislación del país receptor protege suficientemente los datos.
4. Normas Corporativas Vinculantes (BCRs): pensadas para grupos multinacionales. Proceso largo y costoso, raramente aplicable a startups.

Cuánto puede costar no tenerlo

El art. 83.4.a RGPD establece que las infracciones de las obligaciones del encargado —incluido el incumplimiento del art. 28— pueden sancionarse con multas de hasta 10 millones de euros o el 2% de la facturación mundial anual total del ejercicio precedente, eligiéndose la cantidad más elevada.

La AEPD ha sancionado en los últimos años a empresas por ausencia de DPA con sus proveedores de servicios de correo electrónico, plataformas de gestión de clientes y herramientas de análisis web. Las multas en pymes y startups suelen oscilar entre 5.000 y 200.000 euros, pero el daño reputacional y el coste de gestión de la crisis suelen ser mayores que la sanción económica.

Más allá de la sanción, una brecha de seguridad en un proveedor sin DPA correcto puede exponer a la startup a reclamaciones directas de usuarios bajo el art. 82 RGPD, que reconoce el derecho a indemnización por daños materiales e inmateriales.

Checklist: ¿tienes los DPAs en orden?

Preguntas frecuentes sobre DPA y RGPD

¿Necesito un DPA aunque solo tenga 10 clientes?

Sí. El RGPD no establece umbrales de volumen de datos para la obligación del art. 28. Desde el momento en que un tercero trata datos personales en tu nombre —aunque sean pocos— necesitas el DPA. Las obligaciones aplican a todas las empresas que traten datos de personas en la UE, independientemente de su tamaño. Las microempresas sí tienen ciertas excepciones (por ejemplo, en el registro de actividades del art. 30.5), pero no en la obligación de suscribir DPAs.

¿Qué diferencia hay entre DPA y cláusulas contractuales tipo (SCCs)?

Son instrumentos distintos aunque se confunden con frecuencia. El DPA regula la relación Responsable-Encargado dentro del RGPD (art. 28). Las SCCs son el mecanismo para legalizar la transferencia internacional de esos datos a un país sin decisión de adecuación (art. 46.2.c RGPD). En muchos DPAs con proveedores americanos, ambos elementos van integrados en el mismo documento: el DPA incluye las SCCs como anexo o módulo específico.

¿Puedo usar el DPA genérico que ofrece el proveedor o necesito negociar uno propio?

Depende de tu posición negociadora y del perfil del proveedor. Para grandes SaaS (Google, Microsoft, HubSpot, Stripe), el DPA estándar es jurídicamente válido y prácticamente no negociable: impones tus condiciones via la selección de configuraciones disponibles en el panel, no via negociación contractual. Para proveedores más pequeños o cuando el tratamiento sea especialmente sensible (datos de salud, datos financieros, datos de menores), es recomendable negociar un DPA adaptado que cubra mejor tu exposición específica.

¿Qué pasa si mi proveedor no quiere firmar un DPA?

Si un proveedor se niega a firmar un DPA o no ofrece uno, no deberías usar ese servicio para tratar datos personales de tus usuarios. Usar un proveedor sin DPA es una infracción del art. 28 RGPD de la que respondes tú como Responsable. En la práctica, hoy en día cualquier proveedor de software serio tiene su DPA disponible. Si no lo tienen, es una señal de alerta sobre su madurez en cumplimiento.

¿Cada cuánto debo revisar mis DPAs?

Al menos una vez al año, y siempre que: (1) añadas un nuevo proveedor a tu stack, (2) un proveedor existente cambie sus términos o su lista de subencargados, (3) cambie la regulación aplicable (como ocurrió con la invalidación de Privacy Shield en 2020 o la aprobación del EU-US DPF en 2023), o (4) incorpores nuevas categorías de datos o nuevas finalidades de tratamiento.