Checklist del DPA y el RGPD: qué exigir a todo proveedor de módulos de e-commerce

Todo módulo de e-commerce que toque datos de clientes necesita un Acuerdo de Tratamiento de Datos (DPA). La mayoría de comercios lo tratan como un mero trámite de firma en el alta y no vuelven a mirarlo nunca más. Y entonces llega el auditor.

Este es el checklist que tu DPD debería repasar para cada módulo que aparece en tu política de privacidad. Es también lo que ofrecemos a los clientes de sectores regulados cuando nos piden nuestro DPA.

1. ¿Existe realmente un DPA?

A veces el "DPA" es una frase dentro de las Condiciones del Servicio. Eso no es un DPA. Un DPA es un documento aparte con estos elementos obligatorios del artículo 28 del RGPD:

• Objeto y duración del tratamiento
• Naturaleza y finalidad del tratamiento
• Tipo de datos personales + categorías de interesados
• Obligaciones + derechos del responsable del tratamiento
• Mecanismo de aprobación de subencargados
• Mecanismo de transferencias internacionales (cláusulas contractuales tipo si procede)
• Supresión / devolución de datos al finalizar el tratamiento

Si el "DPA" del proveedor de tu módulo no tiene estos elementos, no es un DPA. No lo uses como tal.

2. ¿Cuál es la lista de subencargados?

La lista de subencargados es la página con más datos de cualquier DPA. Léela. En concreto, busca:

• Dónde están. ¿UE, EE. UU., ambos? Los subencargados ubicados en EE. UU. añaden complejidad al mecanismo de transferencia.
• Qué tratan. Alojamiento (casi siempre sin problema). Envío de correo (Bring SES / Postmark, etc.). Analítica (aquí es donde rastrear-el-rastreo se vuelve raro). Procesamiento de pagos (Stripe, Adyen, etc.)
• Notificación de cambios. La mayoría de los DPA permiten al proveedor añadir un subencargado avisando con 30 días. Algunos les dejan hacerlo en silencio. Márchate de los silenciosos.

3. Transferencias internacionales

Si algún subencargado está fuera del EEE, debe existir un mecanismo de transferencia. Tras Schrems II (2020), las cláusulas contractuales tipo (SCC) + una evaluación de impacto de la transferencia son el mecanismo práctico. Algunos proveedores siguen citando el "Privacy Shield" — llevan más de 4 años de retraso; no te fíes de ellos.

Las decisiones de adecuación (Reino Unido, Corea del Sur, partes de EE. UU. bajo el DPF) son válidas cuando proceden. Verifícalo en la página de adecuación de la Comisión Europea, no en el blog del proveedor.

4. Supresión de datos

Cuando dejas de usar el módulo, ¿qué pasa con los datos que el proveedor ha ido acumulando? El DPA debería especificar:

• Una supresión tras un plazo (normalmente 30–180 días después de finalizar el contrato).
• Un mecanismo para que solicites la supresión durante la vigencia del contrato (para propagar las solicitudes de supresión de clientes del RGPD).
• Un certificado de supresión que puedas conservar para el rastro de auditoría.

Los módulos autoalojados tienen aquí una simplificación: no hay datos del lado del proveedor, así que el DPA puede ser sustancialmente más corto. El DPA de NP Rewards Pro tiene dos páginas porque nosotros no tratamos datos de clientes — lo hace tu PrestaShop.

5. El derecho de auditoría

El artículo 28(3)(h) del RGPD otorga al responsable del tratamiento el derecho a auditar al encargado. En la práctica rara vez se ejerce, pero debería figurar en el DPA. Busca:

• Derecho a auditoría anual O un sustituto (p. ej., certificado ISO 27001).
• Plazo de preaviso razonable (más de 30 días).
• Asignación del coste de la auditoría (normalmente lo paga el responsable).

Los proveedores que rechazan los derechos de auditoría o los esconden detrás de planes premium — márchate.

6. Notificación de brechas

72 horas es el plazo de notificación frente al regulador (artículo 33 del RGPD). El DPA debería especificar un plazo más estrecho del encargado al responsable — normalmente de 24–48 horas — para que el responsable tenga tiempo de preparar la notificación al regulador.

7. La cuestión de la minimización de datos

No es estrictamente un elemento del DPA, pero merece la pena preguntarlo: ¿trata el módulo datos que en realidad no necesita? Infractores habituales:

• Módulos de verificación de edad que capturan y almacenan la fecha de nacimiento cuando solo necesitan un booleano.
• Módulos de búsqueda que envían todos los datos de sesión al SaaS cuando la relevancia solo necesita consultas + clics.
• Plataformas de fidelización que extraen todo el historial de pedidos cuando bastarían los agregados mensuales.

La minimización de datos es la forma más barata de reducir el riesgo del RGPD. Si un proveedor defiende que un dato concreto es "necesario", pídele que señale la funcionalidad específica que habilita. Si no puede, plántate.

Las señales para marcharse

1. No hay un documento DPA aparte.
2. Cambios de subencargados sin previo aviso.
3. Se sigue citando el "Privacy Shield".
4. No se ofrece certificado de supresión.
5. No se especifica plazo de notificación de brechas.
6. Derechos de auditoría bloqueados tras planes premium.

Cualquiera de estas es una señal de alerta. Dos son un no rotundo.

En resumen

Los DPA son papeleo hasta que dejan de serlo. Por €100/año en cuotas de módulo, deberías estar obteniendo la misma calidad de DPA que exigirías a un contrato SaaS de €100k. El mercado ha evolucionado para hacer esto realista; si un proveedor no puede cumplirlo, eso dice mucho sobre su madurez operativa.