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:
Cargando el artículo…
Cómo firmar los Data Processing Agreements correctos con tu hosting, CDN, pasarela de pago y plugins SaaS. Cláusulas que son red flags, plantilla mínima defendible y el inventario vivo que tu auditoría exige.
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:
Access logs, logs de plugins, WooCommerce logs y logs de email transaccional acumulan emails, IPs y teléfonos sin que nadie los revise. Cómo auditarlos, sanitizarlos y definir retención sin perder observabilidad.
Guía técnica y legal para procesar solicitudes de acceso, rectificación, cancelación y oposición en WordPress/WooCommerce. Qué borrar, qué retener por obligación legal, cómo responder en plazo y dejar evidencia firmada.
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.
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:
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.
Un DPA defendible incluye al menos estos ocho puntos. Si falta alguno, negociá antes de firmar.
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.
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).
Lista específica de sub-procesadores con derecho a subcontratar, y procedimiento para cambios:
Si el DPA dice "el encargado puede subcontratar libremente", red flag. Perdés trazabilidad completa.
Si el procesador procesa datos fuera de tu jurisdicción (la mayoría de los SaaS sí), necesitás salvaguardas:
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.
Anexo específico con medidas concretas:
"Aplicamos medidas de seguridad adecuadas" sin detalle no es medida técnica, es marketing. Exigí el anexo específico.
Si el DPA dice "notificará sin demora indebida" sin plazo concreto, cambialo. Ambiguo es inútil.
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.
Si al leer el DPA encontrás alguna de estas, frená.
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.
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.
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).
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.
Sin plazo concreto es inejecutable.
Negociá: 24 horas para brechas de alta gravedad (datos sensibles, gran volumen), 72 horas para el resto.
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.
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.
El inventario no es un Excel que hacés una vez. Es un documento vivo que refleja la realidad operativa.
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 |
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.
Primera auditoría casi siempre revela sorpresas. Las técnicas para encontrarlos:
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.
Cabeceras HTTP del frontend. Inspeccionar <head> del sitio público en busca de scripts externos: GA, GTM, Meta Pixel, chatbots, widgets.
Requests salientes. En Chrome DevTools Network Tab, filtrar por dominios externos durante un checkout completo. Cada dominio no tuyo es un procesador potencial.
DNS y CDN. Revisar los records DNS y la configuración de CDN. ¿Quién resuelve tu dominio? ¿Quién sirve los estáticos?
Suscripciones de pago del negocio. Lista de cargos recurrentes en la tarjeta corporativa. Cada SaaS que pagás mensualmente es un procesador.
Emails de "new feature" y onboarding. Los proveedores activos mandan newsletters. Buscar en la bandeja del email principal revela proveedores olvidados.
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 inventario se desactualiza al ritmo al que incorporás o quitás proveedores. Sin proceso, en seis meses está obsoleto.
Antes de firmar con un proveedor, tres pasos:
Evaluación de datos. Qué datos recibiría, con qué finalidad, durante cuánto tiempo. Si no hay necesidad clara, no lo incorpores.
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.
Registro en el inventario. Fila nueva con todas las columnas completas. Fecha, responsable interno, renovación próxima.
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.
Cuando dejás de usar un proveedor, no alcanza con cancelar la suscripción. Hay que:
Inventario automático del día 1: detecta cada plugin, script externo y llamada saliente. Compara contra DPAs en archivo y alerta cuando hay procesador sin contrato o DPA vencido. Reporte listo para la autoridad.
Disponible hoy: Mientras tanto, protegé tu sitio hoy con Drako — $9/mes.
Empezar con DrakoNo 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.
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.
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.
Sí, aunque la ley local no use la palabra 'DPA'. Cualquier procesador que reciba datos personales de tus clientes necesita un contrato que defina: qué datos procesa, con qué finalidad, con qué medidas de seguridad y durante cuánto tiempo. Bajo GDPR se llama DPA; bajo LATAM a menudo es una cláusula del contrato marco o un anexo específico. El contenido es lo que cuenta, no el nombre.
No. El 'cumplimos con GDPR' de marketing no es un contrato. Necesitás un documento firmado donde el hosting se obligue contractualmente contigo. Si no lo tienen o no quieren firmarlo, ese proveedor no es apto para procesar datos de tus clientes —independientemente de su reputación.
Cualquier cláusula que debilite tu posición: transferencias a terceros países sin salvaguardas, limitación de responsabilidad del procesador a un mes de facturación, derecho del proveedor a modificar el DPA unilateralmente sin notificación, ausencia de plazo para notificar brechas, prohibición de auditoría. Si ves alguna de estas, negociá o cambiá de proveedor.
Solo con los plugins que envían datos a servicios externos (no los que procesan localmente). Un plugin de caché no necesita DPA. Un plugin que sincroniza con Mailchimp, sí —y el DPA es con Mailchimp, no con el desarrollador del plugin. El plugin es el conducto; el procesador real es el servicio destino.
Mucho más de los que creés. Entre 15 y 40 en un sitio de tamaño medio: hosting, CDN, DNS, email transaccional, pasarela de pago, SMS (si hay 2FA o notificaciones), analytics, chatbot, CRM, remarketing, newsletter, backup, monitoreo, soporte. La primera auditoría casi siempre revela proveedores olvidados que alguien del equipo integró hace dos años.
Vos sos responsable frente al titular del dato. El sub-procesador es responsable frente a vos de la cadena completa. Un buen DPA obliga al sub-procesador a imponer las mismas obligaciones a sus sub-sub-procesadores, y a notificarte cambios en esa cadena. Si tu DPA con un proveedor no menciona sub-sub-procesadores, estás asumiendo todo el riesgo ciego.
Producto mencionado
Compliance continuo automatizado
Mantiene evidencia de PCI-DSS, SOC2, ISO, GDPR en tiempo real. La auditoría anual deja de ser un infierno.
Disponible hoy
Mientras tanto, protegé tu sitio hoy con Drako — $9/mes.
Cómo etiquetar qué datos son PII en tu WordPress, cuánto tiempo deberías retenerlos y qué técnica de anonimización aplica en cada caso. Hashing, tokenización, generalización y supresión, con ejemplos reales de WooCommerce.