Esta base no varía de un proveedor a otro: es la ley la que la fija, no una política comercial. Lo que varía es el nivel de precisión con el que se cumple cada cláusula: un plazo de notificación cuantificado o vago, subcontratistas nombrados o ignorados. Esta guía detalla cada cláusula obligatoria, con la DPA pública de Aurabase como ejemplo concreto, y se basa en nuestra guía GDPR y soberanía de la UE para el marco legal más amplio.
Lo esencial
- Una DPA es obligatoria desde que existe un tratamiento de datos personales (Art. 28 RGPD), independientemente del nivel de precio suscrito.
- Ocho cláusulas están fijadas por la propia ley (Art. 28 §3): instrucciones documentadas, confidencialidad, seguridad, subcontratistas, asistencia en los derechos, asistencia en materia de seguridad, destino de los datos al final del contrato, derecho de auditoría.
- El RGPD no impone ningún plazo numérico para la notificación de una infracción por parte del subcontratista al responsable del tratamiento (“sin demora indebida”): una DPA seria añade una cifra precisa.
- Se debe nombrar la lista de subencargados, con aviso de cambio y derecho a objetar, no una fórmula vaga del tipo “nuestros socios”.
- El DPA de Aurabase se puede firmar con un clic desde Studio (plan Pro); La exportación de PDF de autoservicio aún no está disponible en el momento de escribir este artículo.
¿Qué es una DPA y cuándo se vuelve obligatoria?
Un DPA es el contrato que rige legalmente a un proveedor que actúa como subcontratista de datos personales, en el sentido deartículo 28 del RGPD. Se vuelve obligatorio en el momento en que un responsable del tratamiento, usted o su empresa, confía el tratamiento de datos personales a un tercero. Este es sistemáticamente el caso de un backend como servicio: cuentas de usuario, correos electrónicos, direcciones IP y contenido de la aplicación, todo pasa por su infraestructura.
La DPA no son las condiciones generales de uso. Los T&C cubren la relación comercial general: facturación, propiedad del contenido, terminación. La DPA cubre específicamente el tratamiento de datos personales, con cláusulas fijadas por ley y en principio no negociables. Su redacción precisa puede variar de un proveedor a otro. Un proveedor que sólo ofrece UGE, sin un DPA separado, no cumple el requisito del artículo 28.
Las ocho cláusulas que debe contener un DPA backend
El artículo 28, apartado 3 del RGPD establece ocho obligaciones que el contrato debe imponer al subcontratista, desde la instrucción documentada hasta el derecho de auditoría del responsable. Estas ocho cláusulas proceden del propio texto reglamentario. Un proveedor no puede eliminarlos ni sustituirlos por algo más vago.
(a) Procesamiento siguiendo instrucciones documentadas
El procesador solo procesa los datos siguiendo instrucciones escritas del controlador, incluso para su transferencia a un tercer país sin una decisión de adecuación.
(b)Confidencialidad del personal
Las personas autorizadas para procesar los datos se comprometen contractualmente a la confidencialidad.
(c) Medidas de seguridad (Art. 32)
Cifrado, control de acceso, pruebas periódicas: medidas técnicas y organizativas adecuadas al riesgo del tratamiento.
(d)Subprocesadores
Autorización previa, general o específica, y notificación de cualquier cambio con derecho de oposición del responsable.
e)Asistencia a los derechos de las personas
El procesador ayuda al controlador a responder a las solicitudes de acceso, rectificación, supresión y portabilidad.
(f)Asistencia y notificación de seguridad
Asistencia con notificación de violaciones, análisis de impacto y consulta previa con la autoridad si es necesario.
(g) Disposición de los datos al finalizar el contrato
Supresión o restitución de todos los datos a criterio del responsable, salvo obligación legal de conservación.
h) Derecho de auditoría del gestor
Suministro de la información necesaria para demostrar el cumplimiento del derecho de auditoría del subcontratista.
Lo que distingue una DPA que realmente funciona de un modelo copiado y pegado sin adaptación es la precisión con la que se completa cada cláusula, no su simple presencia en el resumen del documento.
Por qué la lista de subcontratistas debe ser nombrada, no genérica
La obligación (d) requiere una lista nombrada de subprocesadores, no una fórmula genérica como "nuestros socios técnicos". El responsable del tratamiento debe poder identificar a cada tercero que toque sus datos, su función precisa y su ubicación.
La DPA pública de Aurabase enumera, por ejemplo, seis subcontratistas nombrados, clasificados por función. El hosting de infraestructura reúne a Scaleway y Hetzner, dos proveedores con sede en la UE, con Mollie (Países Bajos) para el pago. Los SMS de autenticación pasan por Twilio (Irlanda), las notificaciones push por Apple y Google, y los certificados TLS por Let’s Encrypt. Cualquier cambio de subcontratista está sujeto a aviso con 30 días de anticipación con derecho a oposición, según se documenta en la página.
En el momento de escribir este artículo, la infraestructura de producción verificada en el código de Aurabase sigue alojada en Hetzner (Alemania, Finlandia). La lista de subcontratistas de una DPA puede variar entre dos versiones. Compruebe siempre la fecha de la versión vigente antes de citarla en su propio registro de tratamiento (Art. 30 RGPD), independientemente del proveedor evaluado.
Cuando un subencargado procesa datos fuera de la UE, la APD debe hacer referencia a una garantía de transferencia reconocida, generalmente las cláusulas contractuales tipo adoptadas por la Comisión Europea (decisión 2021/914). La nacionalidad de la empresa que aloja o procesa sus datos también importa, independientemente de la región elegida, consulte nuestro artículo sobre la nacionalidad del proveedor y la Ley CLOUD.
Cómo la DPA debería cubrir los derechos de los interesados
La obligación (e) exige que el subcontratista asista al responsable del tratamiento en la respuesta a las solicitudes de los interesados: acceso, rectificación, supresión, portabilidad, oposición, limitación. En la práctica, esta asistencia se mide por dos cosas concretas: un canal de contacto documentado y un tiempo de respuesta cuantificado.
El RGPD fija este plazo en un mes para el responsable del tratamiento, ampliable en dos meses para solicitudes complejas (Art. 12 RGPD). La DPA de Aurabase utiliza este mismo plazo, aproximadamente 30 días, para cualquier solicitud dirigida a privacy@aurabase.cloud. Una exportación legible por máquina permanece disponible a través del comando CLI aura export --user <email> --format jsonl, para solicitudes de acceso y portabilidad.
Una exportación estructurada (JSON, CSV) se considera portabilidad en el sentido del artículo 20 del RGPD. Por lo general, una exportación de PDF no estructurado no es suficiente para cumplir con esta obligación.
El plazo de notificación: lo que exige la ley, lo que añade una DPA seria
El RGPD distingue dos obligaciones de notificación, a menudo confusas. El responsable del tratamiento debe notificar a la autoridad de control (la CNIL en Francia) dentro de las 72 horas siguientes a su conocimiento de una infracción que pueda crear un riesgo para las personas (Art. 33 §1). El subcontratista debe informar al responsable “sin demora indebida” (Art. 33 §2): la ley no fija ninguna cifra precisa para este segundo plazo.
Aquí es donde una DPA seria añade precisión que la ley por sí sola no proporciona. La DPA de Aurabase se compromete a un plazo máximo de 48 horas para notificar al responsable, con un informe detallado de la incidencia en el plazo de cinco días hábiles. Una DPA que no cuantifica ningún plazo transfiere un riesgo de reactividad que el gestor no puede controlar por sí mismo.
¿Qué debe prever la DPA sobre el destino de los datos al final del contrato?
La obligación (g) exige la supresión o restitución de todos los datos personales al finalizar el contrato, a elección del responsable, con destrucción de las copias existentes salvo que exista una obligación legal de conservación. Esta cláusula debe especificar un plazo concreto, no sólo el principio.
| categoría | Datos en cuestión | Duración |
|---|---|---|
| Contenido de la aplicación | Cualquier dato almacenado en las tablas de Postgres del proyecto. | Duración del proyecto + 30 días después de la eliminación |
| Archivos | Objetos binarios en depósitos de almacenamiento | Duración del proyecto + 30 días |
| Facturación | Nombre, dirección, número de IVA, historial | 10 años (obligación legal) |
Duraciones precisas, en lugar de una fórmula del tipo “dentro de un tiempo razonable”, es lo que debe buscar en el DPA de un proveedor antes de firmar. Una duración no cuantificada complica la propia prueba de cumplimiento en caso de inspección.
Lista de verificación antes de firmar un DPA con un backend como servicio
Esta lista de verificación se refiere al contenido de la propia DPA. Para obtener una selección más amplia de un proveedor backend compatible (hosting, empresa matriz, seguridad), consulte nuestra lista de verificación completa de cumplimiento del RGPD para un BaaS.
- ¿Están presentes los ocho apartados del artículo 28 §3 o algunos hacen referencia a un documento de un tercero que no se puede encontrar?
- ¿Los subprocesadores se nombran individualmente, con su función y ubicación?
- ¿El plazo de notificación de infracciones se mide en horas o se mantiene “lo antes posible”?
- ¿El destino de los datos al final del contrato especifica una duración exacta de la eliminación, y no sólo el principio?
- ¿La DPA hace referencia a cláusulas contractuales tipo para cualquier transferencia fuera de la UE identificada en la lista de subcontratistas?
- ¿El documento está fechado y tiene visible la fecha de la última actualización?
Preguntas frecuentes
El DPA es solo una parte del cumplimiento del RGPD por parte del backend. La lista de verificación completa, que también cubre el alojamiento, la empresa matriz y la postura de seguridad, se detalla en nuestra lista de verificación de cumplimiento del RGPD para un BaaS.