📝DPAs con hosting, CDN y plugins: el inventario de sub-procesadores que tu WordPress necesita

Abro el admin de un WooCommerce que vende en tres países de LATAM y hago una lista rápida de a qué servicios externos manda datos:

• Hosting: SiteGround (EE.UU. con datacenter en Países Bajos).
• CDN: Cloudflare (EE.UU., red global).
• DNS: Cloudflare.
• Backups: UpdraftPlus → Amazon S3 (Virginia, EE.UU.).
• Email transaccional: WP Mail SMTP → SendGrid (Twilio, EE.UU.).
• Newsletter: Mailchimp (EE.UU., sub-procesa con AWS).
• Pasarela: Stripe (EE.UU., sub-procesa con Google Cloud).
• Analytics: Google Analytics 4 + Google Ads tag.
• Remarketing: Meta Pixel.
• Chatbot: Intercom (EE.UU.).
• Reviews: Judge.me (Nueva Zelanda, servidores en EE.UU.).
• Monitoreo uptime: UptimeRobot.
• SMS 2FA: Twilio.
• Tag management: Google Tag Manager.

Catorce proveedores. Catorce posibles puntos de brecha. Catorce contratos que deberían existir con cláusulas específicas de tratamiento de datos.

¿Cuántos DPAs firmados hay en la carpeta de contratos del cliente? Tres. Y uno es del 2021, desactualizado.

Esta es la realidad de la mayoría de los ecommerce LATAM. El inventario de sub-procesadores es más largo de lo que nadie recuerda, los DPAs están incompletos o ausentes, y el día que haya una brecha en cualquiera de esos proveedores, no hay cadena de custodia ni responsabilidad definida.

Este artículo es el playbook para armar el inventario, firmar los DPAs correctos, reconocer las cláusulas peligrosas y mantener el sistema vivo cuando agregás o reemplazás un proveedor.

Qué es un DPA y por qué no es opcional

Un Data Processing Agreement (DPA) —Acuerdo de Procesamiento de Datos, Contrato de Encargo, Acuerdo de Tratamiento según la jurisdicción— es el contrato que define las obligaciones de un tercero que procesa datos personales por cuenta tuya.

Los roles son tres:

• Titular: la persona cuyos datos se tratan (tu cliente).
• Responsable del tratamiento (controller): quien decide para qué y cómo se usan los datos (vos, como ecommerce).
• Encargado del tratamiento (processor): quien trata los datos por instrucciones del responsable (tu hosting, tu CRM, tu pasarela).

El DPA regula la relación responsable-encargado. Sin DPA, vos sos responsable de todo lo que haga el encargado, incluso cosas que no podrías haber previsto. Con DPA, delegás obligaciones concretas y tenés recurso legal si el proveedor incumple.

En GDPR el DPA es explícito (artículo 28). En LATAM el nombre varía —Argentina habla de "cesión y encargo de tratamiento", México de "encargado del tratamiento", Colombia de "encargado"— pero la obligación sustantiva es la misma: contrato firmado con medidas de seguridad, finalidad limitada y responsabilidades claras.

Los ocho componentes mínimos

Un DPA defendible incluye al menos estos ocho puntos. Si falta alguno, negociá antes de firmar.

1. Objeto y finalidad del tratamiento

Qué datos se tratan (categorías: nombre, email, direcciones, pagos), con qué finalidad específica (procesar pedidos, enviar facturación, atender soporte), y por qué medios (servidores propios del proveedor, sub-procesadores).

Si el DPA dice "todos los datos necesarios para prestar el servicio" sin especificar, no es suficiente.

2. Duración del tratamiento

Mientras dure la relación contractual + X meses definidos + obligaciones de destrucción al terminar.

La parte crítica: qué pasa al terminar el contrato. El DPA debe obligar al proveedor a devolver o destruir los datos, con evidencia de la destrucción (certificado de destrucción o similar).

3. Obligaciones del encargado

• Tratar solo por instrucciones del responsable.
• Garantizar confidencialidad del personal autorizado.
• Aplicar medidas técnicas y organizativas de seguridad (cifrado, control de acceso, backup, plan de continuidad).
• Asistir al responsable en responder solicitudes de titulares.
• Notificar brechas en plazo definido.

4. Sub-procesadores autorizados

Lista específica de sub-procesadores con derecho a subcontratar, y procedimiento para cambios:

• Notificación previa con plazo (30-60 días típico).
• Derecho del responsable a objetar cambios.
• Obligaciones equivalentes del sub-procesador.

Si el DPA dice "el encargado puede subcontratar libremente", red flag. Perdés trazabilidad completa.

5. Transferencias internacionales

Si el procesador procesa datos fuera de tu jurisdicción (la mayoría de los SaaS sí), necesitás salvaguardas:

• Cláusulas Contractuales Tipo (SCC de UE) para transferencias a terceros países.
• Decisiones de adecuación (GDPR reconoce Uruguay, Argentina en ciertos casos, el EU-US Data Privacy Framework).
• Binding Corporate Rules para grupos empresariales.

En LATAM varía. México y Brasil tienen sus propios esquemas. Asegurate de que el DPA mencione la salvaguarda aplicable y no sea genérico.

6. Medidas técnicas y organizativas

Anexo específico con medidas concretas:

• Cifrado en tránsito (TLS mínimo 1.2, idealmente 1.3).
• Cifrado en reposo (al menos AES-256 o equivalente).
• Control de acceso basado en roles.
• Logs de auditoría con retención.
• Plan de respuesta a incidentes.
• Continuidad y recuperación (RTO/RPO).

"Aplicamos medidas de seguridad adecuadas" sin detalle no es medida técnica, es marketing. Exigí el anexo específico.

7. Notificación de brechas

• Plazo máximo de notificación (72 horas es el estándar GDPR, pero negociá 24-48 horas para casos graves).
• Información obligatoria: naturaleza, datos afectados, número estimado de afectados, medidas correctivas.
• Canal de notificación definido (email específico, portal, contacto nominado).

Si el DPA dice "notificará sin demora indebida" sin plazo concreto, cambialo. Ambiguo es inútil.

8. Auditoría y terminación

• Derecho del responsable a auditar el cumplimiento (directamente o vía tercero).
• Procedimiento de auditoría (frecuencia máxima, costo, confidencialidad).
• Obligación de devolver o destruir datos al terminar.
• Plazo de cura para incumplimientos.

Algunos proveedores grandes (AWS, Google, Microsoft) ofrecen en lugar de auditoría directa sus reportes SOC 2, ISO 27001, etc. Es aceptable si los reportes son recientes y cubren el alcance, pero asegurate de que el DPA explicite esa sustitución.

Las siete cláusulas red flag

Si al leer el DPA encontrás alguna de estas, frená.

1. "El procesador puede modificar este DPA unilateralmente en cualquier momento"

Variantes: "con previa notificación de 30 días pero sin necesidad de aceptación". Es entregar control total de la relación. Cualquier cambio a peor te cae encima automáticamente.

Negociá: modificaciones por mutuo acuerdo; los cambios unilaterales solo pueden ser para agregar protecciones al titular, no quitarlas.

2. "Responsabilidad limitada al equivalente de un mes de facturación"

Común en SaaS baratos. Si tu pasarela te cobra $50/mes y hay una brecha que te cuesta $500k en multas, te cubren $50.

Negociá: para brechas por negligencia grave del procesador, responsabilidad ilimitada o al menos acotada al daño real comprobable.

3. "El procesador se reserva el derecho a usar datos agregados y anonimizados"

Peligroso porque la definición de "anonimizado" rara vez está en el DPA. Puede significar "seudonimizado" en la práctica.

Negociá: definición explícita de anonimización (irreversible, sin posibilidad de re-identificación, auditada), y uso limitado a fines específicos (mejora del servicio, no reventa a terceros).

4. "Las transferencias internacionales se rigen por las políticas vigentes del procesador"

Autopass para transferir datos a cualquier jurisdicción sin salvaguardas.

Negociá: listado específico de países/regiones donde se procesan datos, con salvaguardas legales concretas para cada uno.

5. "El procesador notificará brechas sin demora indebida"

Sin plazo concreto es inejecutable.

Negociá: 24 horas para brechas de alta gravedad (datos sensibles, gran volumen), 72 horas para el resto.

6. "La auditoría está sujeta a la aprobación discrecional del procesador"

Vacía el derecho de auditoría.

Negociá: derecho de auditoría con procedimiento claro (preaviso 30 días, horario laboral, confidencialidad). Frecuencia máxima razonable (1-2 veces al año). Costo del responsable salvo hallazgo grave.

7. "Al terminar el contrato, los datos se eliminarán según la política de retención del procesador"

Política que vos no controlás. Pueden retener "por razones legítimas" indefinidamente.

Negociá: plazo concreto de destrucción post-terminación (30-90 días), con certificado de destrucción. Excepciones solo por obligación legal específica, documentadas.

Armá el inventario vivo de sub-procesadores

El inventario no es un Excel que hacés una vez. Es un documento vivo que refleja la realidad operativa.

Estructura mínima de la matriz

Una fila por sub-procesador con estas columnas:

| Columna | Ejemplo | |---------|---------| | Nombre | SendGrid (Twilio) | | Función | Envío de emails transaccionales | | Categoría de datos | Email, nombre, contenido del email | | Categoría de titulares | Clientes, suscriptores | | Jurisdicción del procesamiento | EE.UU. | | Sub-sub-procesadores | AWS, Google Cloud | | Salvaguarda para transferencia | DPF, SCC | | Fecha DPA firmado | 2026-01-15 | | Versión DPA | v4.2 | | Próxima revisión | 2027-01-15 | | Contacto privacidad | privacy@sendgrid.com | | Base legal | Contrato |

Dónde vive el inventario

En un sistema versionado (Git, Notion con historial, Confluence). Nunca en un Excel que se edita sin rastro. Cuando llegue una auditoría vas a necesitar mostrar la evolución: cuándo agregaste cada proveedor, por qué, con qué DPA.

Cómo descubrir proveedores olvidados

Primera auditoría casi siempre revela sorpresas. Las técnicas para encontrarlos:

1. Plugins activos de WordPress. Revisar cada uno y documentar si envía datos externos. El nombre del plugin y su página web dan pistas. Los que dicen "sync with..." o tienen API keys casi siempre son procesadores.

2. Cabeceras HTTP del frontend. Inspeccionar <head> del sitio público en busca de scripts externos: GA, GTM, Meta Pixel, chatbots, widgets.

3. Requests salientes. En Chrome DevTools Network Tab, filtrar por dominios externos durante un checkout completo. Cada dominio no tuyo es un procesador potencial.

4. DNS y CDN. Revisar los records DNS y la configuración de CDN. ¿Quién resuelve tu dominio? ¿Quién sirve los estáticos?

5. Suscripciones de pago del negocio. Lista de cargos recurrentes en la tarjeta corporativa. Cada SaaS que pagás mensualmente es un procesador.

6. Emails de "new feature" y onboarding. Los proveedores activos mandan newsletters. Buscar en la bandeja del email principal revela proveedores olvidados.

7. Entrevistas cortas con el equipo. Preguntarle a marketing, soporte y dev qué usan. Suele haber 2-3 herramientas que solo conoce una persona y nadie más del equipo sabe que existen.

El proceso de onboarding y offboarding

El inventario se desactualiza al ritmo al que incorporás o quitás proveedores. Sin proceso, en seis meses está obsoleto.

Onboarding de proveedor nuevo

Antes de firmar con un proveedor, tres pasos:

1. Evaluación de datos. Qué datos recibiría, con qué finalidad, durante cuánto tiempo. Si no hay necesidad clara, no lo incorpores.

2. Revisión del DPA. Contra la checklist de ocho componentes y siete red flags. Si falta algo esencial o hay red flag grave, negociar o rechazar.

3. Registro en el inventario. Fila nueva con todas las columnas completas. Fecha, responsable interno, renovación próxima.

4. Actualización de la política de privacidad pública. Si tu política lista sub-procesadores (muchas jurisdicciones lo exigen o recomiendan), incluir el nuevo.

Offboarding de proveedor

Cuando dejás de usar un proveedor, no alcanza con cancelar la suscripción. Hay que:

1. Revocar accesos API y credenciales. Que la integración no siga funcionando desde WordPress.
2. Solicitar destrucción de datos según el DPA. Guardar el certificado.
3. Eliminar del inventario o marcar como "terminado" con fecha.
4. Actualizar la política pública si estaba listado.
5. Verificar que no queden exports activos (webhooks, SFTP, feeds que seguían corriendo).

Matriz de riesgo: priorizá dónde enfocás el esfuerzo

No todos los proveedores tienen el mismo peso. La matriz de riesgo te dice dónde invertir tiempo en negociación vs. dónde aceptar DPA estándar.

Clasificá cada proveedor en dos dimensiones: volumen de datos y sensibilidad de datos.

Alto volumen + alta sensibilidad: hosting, pasarela de pago, CRM con historial. Requieren DPA negociado, revisión anual, auditoría periódica.

Alto volumen + baja sensibilidad: CDN (procesa IPs masivamente pero nada más), analytics anonimizado. DPA estándar es aceptable; revisión cada 18 meses.

Bajo volumen + alta sensibilidad: SMS 2FA (teléfonos + códigos efímeros), helpdesk con conversaciones sensibles. DPA específico con cláusulas de retención estricta.

Bajo volumen + baja sensibilidad: monitoreo uptime, servicios esporádicos. DPA estándar, revisión cada 2 años.

Este ejercicio prioriza. Negociar intensivamente con el monitoreo uptime mientras dejás el hosting con DPA genérico es el error inverso.

Errores comunes en LATAM

Suponer que "el proveedor es grande, no voy a revisar el DPA". AWS, Google, Azure tienen DPAs estándar sólidos pero con cláusulas por defecto agresivas en responsabilidad y sub-sub-procesadores. Leé y ajustá dentro de lo negociable.

Firmar el DPA con el reseller en lugar del procesador real. Si contratás SendGrid vía una agencia que revende, el DPA debería ser con SendGrid (el procesador real), no con la agencia. Pediselo a la agencia o firmá directo.

No renovar los DPAs cuando se actualizan. Los proveedores grandes publican nuevas versiones (SCCs nuevas, cláusulas actualizadas post-Schrems II). Seguí sus páginas de privacidad y firmá addenda cuando toca.

Ignorar los free tiers. Usás el free tier de Mailchimp para newsletters pequeños. Igual es procesamiento de PII. Igual necesitás DPA. Los free tiers suelen tener DPA automático al aceptar términos —pero tenés que encontrar el documento y archivarlo.

Dejar los plugins "de prueba" instalados. Un dev probó un plugin hace un año, se olvidó, sigue conectado a un SaaS que olvidaste. Cada plugin activo es una potencial transferencia no documentada. Auditoría trimestral: desactivar y eliminar lo no usado.

No traducir los DPAs en inglés. Muchos tribunales LATAM exigen traducción oficial al español del contrato marco. Si hay disputa, un DPA solo en inglés puede ser impugnable. Pediselo al proveedor o hacé traducción jurada.

Cierre

El inventario de sub-procesadores es el mapa que decide cuán responsable sos en caso de brecha. Sin mapa, tu posición es "no sabía quién tenía qué"; con mapa, tu posición es "acá está la cadena, acá el DPA, acá la notificación".

Los DPAs no protegen de la brecha —la brecha puede ocurrir igual—. Protegen de dos cosas: de que la autoridad te impute la brecha entera cuando el responsable directo es el procesador, y de que el procesador te deje sin recurso legal cuando incumple.

Armar el inventario vivo la primera vez lleva de una a tres semanas de trabajo. Mantenerlo después son 30 minutos al mes si el proceso está definido. Esos 30 minutos son la diferencia entre una auditoría que terminás en dos horas y una que te consume un mes y un susto.

Tu WordPress es una red de proveedores interconectados. Mapearla es el trabajo inicial; mantenerla es el trabajo recurrente; demostrarla es el trabajo que un día va a salvarte.