En una frase. Una startup SaaS es, casi siempre, encargada del tratamiento de los datos de sus clientes, y eso significa que debe firmar un contrato de encargado con cada cliente, controlar a sus subencargados en la nube y construir privacidad desde el diseño en el producto, o perderá contratos enterprise por no poder acreditarlo.
El RGPD startups no es un freno, sino una condición para vender. Los clientes grandes exigen un DPA firmado, un registro de tratamientos y garantías sobre dónde viven los datos antes de contratar. Una startup que llega a esa conversación sin nada preparado pierde el negocio. Esta guía ofrece un enfoque pragmático para cumplir sin ralentizar el producto.
Puntos clave
- El SaaS suele ser encargado del tratamiento de los datos de sus clientes.
- Necesitas un DPA (contrato del art. 28 RGPD) firmado con cada cliente.
- Los proveedores cloud (AWS, GCP, Azure) son subencargados que hay que autorizar y controlar.
- La privacidad desde el diseño evita rehacer el producto más tarde.
- Los clientes enterprise piden RAT, DPA y garantías de transferencia antes de firmar.
1. Encargado o responsable: define tu rol primero
La mayoría de los SaaS B2B tratan datos personales que les confían sus clientes (los usuarios finales, empleados o clientes de esos clientes). En ese escenario, el cliente es el responsable y la startup es el encargado: trata los datos siguiendo las instrucciones del cliente y no puede usarlos para fines propios.
Al mismo tiempo, la startup es responsable de los datos de sus propios empleados, leads y usuarios de su web. Distinguir ambos roles es el primer paso, porque determina qué contratos firmas y qué obligaciones asumes. Si el concepto no te resulta familiar, empieza por el artículo 28 RGPD y las obligaciones del encargado.
Esta distinción no es teórica: define quién responde ante la autoridad y ante los tribunales. Como encargado, tu responsabilidad se limita a tratar los datos según las instrucciones del cliente y a garantizar la seguridad; el cliente responde de la licitud del tratamiento frente a los usuarios finales. Pero el art. 28.10 del Reglamento (UE) 2016/679 contiene una trampa: si el encargado decide por su cuenta los fines o los medios del tratamiento —por ejemplo, usa los datos de los clientes para entrenar un modelo propio de IA sin instrucción del responsable—, pasa a ser responsable de ese tratamiento y asume toda la carga. Para una startup que quiere explotar datos agregados o entrenar modelos, esta frontera es crítica y conviene delimitarla por escrito en el contrato.
2. El DPA: tu documento comercial más importante
El contrato de encargado o Data Processing Agreement (DPA) no es papeleo: es lo que un cliente enterprise revisa antes de firmar. Debe cubrir los elementos del art. 28.3 RGPD:
- Objeto, duración, naturaleza y finalidad del tratamiento.
- Tipos de datos y categorías de interesados.
- Obligación de tratar solo según instrucciones.
- Confidencialidad, seguridad (art. 32), asistencia al responsable.
- Régimen de subencargados y supresión al final del contrato.
Prepara un DPA sólido y estandarizado desde el principio; acelera las ventas. Usa como base nuestro modelo de contrato de encargado.
3. Subencargados y transferencias internacionales
Tu SaaS se apoya en infraestructura de terceros: hosting, correo transaccional, analítica, soporte. Cada uno que trate datos personales es un subencargado, y necesitas:
- Autorización del cliente (general o específica) para usarlos.
- Contrato que imponga a cada subencargado las mismas obligaciones.
- Control de dónde se alojan los datos.
Si alguno procesa datos fuera del Espacio Económico Europeo, entras en el terreno de las transferencias internacionales: necesitas una decisión de adecuación, cláusulas contractuales tipo o una evaluación de la transferencia. Muchos clientes europeos exigirán, además, saber si sus datos salen de la UE. La soberanía del dato se ha convertido en un argumento de venta.
El Comité Europeo de Protección de Datos (EDPB) ha subrayado que el responsable debe poder identificar en todo momento la cadena completa de subencargados. Para una startup esto significa mantener una lista pública y actualizada de subprocesadores —una práctica que los clientes enterprise ya dan por descontada— y comprometerse a avisar con antelación de cualquier cambio, dando al cliente la posibilidad de oponerse. Ocultar un subencargado o cambiarlo en silencio es una de las causas más frecuentes de ruptura de confianza en las auditorías de proveedores, y puede costar la renovación de un contrato.
4. Privacidad desde el diseño en el producto
El art. 25 RGPD obliga a incorporar la protección de datos desde el diseño y por defecto. Para una startup, aplicarlo temprano evita costosas reingenierías:
- Minimización: no pidas ni almacenes datos que no necesitas.
- Configuración por defecto más protectora (opt-in, no opt-out).
- Borrado y exportación: implementa desde el inicio la supresión y la portabilidad para atender derechos.
- Segregación y cifrado de datos por cliente (multitenancy segura).
- Logs de acceso para acreditar la responsabilidad proactiva.
El punto ciego habitual está fuera del producto: el espacio de trabajo interno donde el equipo acumula notas de clientes, candidaturas y listas sin ningún modelo de datos. Si tu equipo trabaja en Notion, esa base necesita su propia entrada en el registro y una revisión de los enlaces públicos antes de la primera auditoría de un cliente enterprise. Lo mismo vale para el CRM: la configuración de Salesforce determina qué se conserva y durante cuánto tiempo, y no viene resuelta de fábrica.
5. Roadmap de cumplimiento en 30 días
Un plan realista para una startup en fase temprana, alineado con el cumplimiento básico de una pyme:
- Días 1-5: inventario de datos y definición de roles (dónde eres encargado y dónde responsable).
- Días 6-12: registro de actividades de tratamiento y mapa de subencargados.
- Días 13-18: DPA estándar y contratos con subencargados; análisis de transferencias.
- Días 19-24: política de privacidad, información en dos capas y procedimiento de derechos.
- Días 25-30: medidas de seguridad (art. 32), plan de respuesta a brechas y privacidad por defecto en el producto.
Con esto, una startup llega a las conversaciones con clientes enterprise con respuestas, no con silencios. En una ronda de inversión, además, la due diligence de datos deja de ser un punto rojo: los inversores revisan cada vez con más atención cómo trata los datos la empresa, porque una infracción latente es un pasivo que puede rebajar la valoración o bloquear una adquisición. Tener el cumplimiento ordenado desde el principio convierte un posible obstáculo en una señal de madurez.
Véase también, para sectores con obligaciones de protección de datos similares: RGPD para empresas de construcción, RGPD para transporte y logística y RGPD para asociaciones y ONG.
FAQ
¿Mi SaaS es responsable o encargado del tratamiento?
Respecto de los datos que te confían tus clientes para prestarles el servicio, normalmente eres encargado y actúas según sus instrucciones. Respecto de los datos de tus propios empleados, leads y usuarios de tu web, eres responsable.
¿Necesito firmar un DPA con cada cliente?
Sí. El art. 28 RGPD exige un contrato de encargado por escrito entre responsable y encargado. Tener un DPA estándar y sólido acelera las ventas, sobre todo con clientes grandes que lo revisan antes de firmar.
¿Puedo usar AWS o Google Cloud siendo encargado?
Sí, pero son subencargados: necesitas autorización del cliente, un contrato que les imponga las mismas obligaciones y control de dónde alojan los datos. Si procesan fuera del EEE, debes amparar la transferencia internacional.
¿Cuándo debe una startup empezar a preocuparse por el RGPD?
Desde el primer dato personal que trata. Aplicar privacidad desde el diseño en el MVP es mucho más barato que rehacer el producto después, y evita perder contratos enterprise por no poder acreditar el cumplimiento.