SaaS y RGPD: cuando tu software actúa como encargado del tratamiento de tus clientes

Q: ¿Una empresa SaaS es responsable o encargada del tratamiento sobre los datos que procesan sus clientes?

La regla general es que el SaaS es encargada del tratamiento (art. 28 RGPD) sobre los datos que el cliente sube a la plataforma para su uso comercial: el CRM contiene clientes de la empresa que lo usa, el ERP contiene proveedores de la empresa-cliente, la plataforma de email marketing contiene suscriptores del cliente. En ese plano, el cliente es responsable del tratamiento y la SaaS es encargada que ejecuta lo que aquel le indica. Pero la SaaS suele actuar también como responsable independiente en otras capas: tratamiento de los datos de sus propios usuarios (la cuenta del administrador, la suscripción, el contacto comercial con la empresa cliente), facturación, análisis de uso agregado del producto, mejora del propio servicio, cumplimiento normativo propio. Esa dualidad debe quedar claramente regulada en los términos de servicio y, sobre todo, en el contrato del art. 28 RGPD que la SaaS firma con cada cliente.

Q: ¿Qué debe ofrecer una SaaS a sus clientes para cumplir el art. 28 RGPD?

Una SaaS profesional debe poner a disposición de sus clientes empresariales un Acuerdo de Tratamiento de Datos (Data Processing Agreement o DPA) que contenga el contenido mínimo del art. 28.3 RGPD: objeto, duración, naturaleza y finalidad del tratamiento, tipos de datos y categorías de interesados, obligaciones del responsable y del encargado, confidencialidad del personal, medidas de seguridad, régimen de subencargados con lista accesible y mecanismo de notificación de cambios, asistencia para derechos del interesado, notificación de brechas, devolución o exportación de los datos al finalizar el contrato y derecho de auditoría. El DPA suele ofrecerse como anexo de adhesión a los términos del servicio, descargable por el cliente o firmado expresamente cuando el cliente lo solicita. Una SaaS que no ofrece DPA está vendiendo un producto que sus clientes no pueden contratar legalmente para datos personales.

Q: ¿Cuándo deja una SaaS de ser encargada y se convierte en responsable independiente?

Cuando la SaaS decide por sí misma finalidades nuevas que el cliente no le ha indicado. Tres situaciones típicas marcan el cambio de rol: cruzar los datos del cliente con los de otros clientes para construir modelos analíticos propios, entrenar modelos de inteligencia artificial generales con datos del cliente sin su autorización específica, y reutilizar los datos para mejorar el producto comercial de la SaaS más allá de la prestación contratada. En cada una de esas situaciones, la SaaS asume finalidades propias y, por tanto, se convierte en responsable independiente sobre esos datos. El régimen aplicable deja de ser el del art. 28 RGPD (encargado) y pasa al art. 6 RGPD (responsable): hace falta base jurídica autónoma, informar a los interesados y cumplir todos los demás deberes. La regla práctica es que la SaaS debe regular contractualmente con sus clientes qué datos se usan solo para la prestación del servicio (encargado) y cuáles se reservan, con consentimiento explícito, para finalidades propias.

Q: ¿Tiene una SaaS que ofrecer a sus clientes garantías sobre los subencargados que utiliza (hosting, CDN, analítica)?

Sí. El art. 28.2 RGPD obliga al encargado a no contratar subencargados sin autorización previa del responsable, ya sea específica o general. En la práctica del SaaS, la autorización suele ser general y se concede en el DPA, pero la SaaS debe mantener una lista accesible y actualizada de los subencargados que usa (AWS, Google Cloud, Azure, Cloudflare, Sentry, Stripe, etc.) y notificar al cliente cualquier cambio significativo con tiempo suficiente para que el cliente pueda oponerse. Cada subencargado debe estar vinculado por las mismas obligaciones de protección de datos que la SaaS, lo que en la práctica se materializa firmando con cada uno un DPA equivalente y trasladando esos compromisos hasta el final de la cadena. Las grandes plataformas cloud ofrecen sus propios DPA estándar; la SaaS debe revisar que cubren los puntos exigidos por el RGPD y, especialmente, las transferencias internacionales si los servidores están fuera del EEE.

Una empresa de software como servicio —un CRM, un ERP, una plataforma de email marketing, una herramienta de gestión de proyectos, un software de RRHH, un product analytics— procesa cada día datos personales que no son suyos, sino de las empresas que la usan. Esa posición particular, ser pieza crítica en la operativa de cientos o miles de empresas-cliente, convierte a la SaaS en uno de los actores con mayor exposición al RGPD del ecosistema digital. Y, al mismo tiempo, en uno donde mejor se puede convertir el cumplimiento normativo en ventaja comercial.

Esta guía explica cómo regula una empresa SaaS su rol bajo el RGPD (Reglamento UE 2016/679) y la LOPDGDD (Ley Orgánica 3/2018): cuándo es encargada del tratamiento, qué documento debe ofrecer a sus clientes empresariales (DPA), cómo gestiona los subencargados, dónde está la frontera entre encargado y responsable independiente y qué cuidar al entrenar modelos o al integrar inteligencia artificial.

El reparto de roles típico en SaaS

Cuando un cliente empresarial contrata una SaaS, conviven al menos dos planos de tratamiento de datos personales con roles diferentes:

Datos que el cliente sube a la plataforma (clientes finales en el CRM, empleados en el software de RRHH, suscriptores en la plataforma de email): el cliente es responsable de esos tratamientos; la SaaS es encargada que ejecuta lo que aquel le indica. Aquí se aplica el régimen del art. 28 RGPD.
Datos del propio cliente como usuario de la SaaS (cuenta del administrador, datos de facturación, log de acceso, contacto comercial): la SaaS es responsable de esos tratamientos. Aquí se aplica el régimen del art. 6 RGPD, con base habitualmente en la ejecución del contrato.

En empresas SaaS bien estructuradas, esta dualidad aparece reflejada con claridad en dos documentos distintos: la política de privacidad del sitio web público (que cubre la captación comercial, el uso del producto y la facturación, donde la SaaS es responsable) y el DPA (Data Processing Agreement) que el cliente empresarial firma o acepta al contratar (que cubre el régimen del art. 28 RGPD para los datos que el cliente subirá).

El DPA: el documento que toda SaaS profesional ofrece a sus clientes

El art. 28.3 RGPD obliga al responsable y al encargado a regular su relación mediante un contrato u otro acto jurídico vinculante con un contenido mínimo concreto. En el mundo SaaS, ese instrumento se llama universalmente Data Processing Agreement (DPA) o Acuerdo de Tratamiento de Datos y suele ofrecerse como anexo de adhesión a los términos del servicio.

Una SaaS profesional pone el DPA a disposición del cliente sin que este tenga que pedirlo, idealmente accesible desde el panel de administración, descargable como PDF firmado o aceptable mediante un check de consentimiento que deja constancia. El DPA debe cubrir:

Cláusula	Qué debe decir en un SaaS
Objeto y duración	Prestación del servicio descrito en los términos de contratación durante la vigencia de la suscripción del cliente.
Naturaleza y finalidad	Almacenar, procesar, analizar y mostrar los datos que el cliente sube según las funcionalidades del producto, sin usarlos para finalidades propias distintas en su rol de encargado.
Tipos de datos e interesados	Identificativos, contacto, datos comerciales, en su caso categorías especiales si el producto lo permite. Interesados: clientes finales, empleados, proveedores del cliente.
Personal de la SaaS	Confidencialidad por contrato, control de altas y bajas, principio del mínimo privilegio en accesos a datos de cliente.
Medidas de seguridad	Cifrado en tránsito y en reposo, control de accesos con doble factor, segregación lógica entre tenants, registro de actividad, copias de seguridad, gestión de vulnerabilidades, certificaciones (ISO 27001, SOC 2) si aplican.
Subencargados	Lista accesible y actualizada (hosting, CDN, monitorización, soporte externo si lo hay), autorización general en el DPA y mecanismo de notificación de cambios.
Transferencias internacionales	Identificación de países fuera del EEE, base de la transferencia (decisión de adecuación, Data Privacy Framework para EE.UU., cláusulas contractuales tipo) y análisis de impacto cuando proceda.
Asistencia para derechos	Herramientas en el producto para que el cliente atienda derechos del interesado (exportación, supresión, rectificación) y procedimiento de soporte cuando se requiere intervención técnica.
Notificación de brechas	Plazo concreto para notificar al cliente cualquier brecha que afecte a sus datos (típicamente 24-48 horas), información mínima y procedimiento de colaboración.
Devolución y supresión	Al finalizar la suscripción, el cliente puede exportar los datos en formato estructurado (CSV, JSON, API). Plazo de retención posterior, normalmente 30-90 días, y supresión segura confirmada.

Subencargados: la cadena que toda SaaS debe documentar

Casi ninguna SaaS opera sola: detrás suele haber un proveedor cloud (AWS, Google Cloud, Azure), una CDN (Cloudflare, Fastly), un servicio de monitorización (Sentry, Datadog), una pasarela de pago (Stripe), una herramienta de soporte (Intercom, Zendesk), un proveedor de correo transaccional (SendGrid, Postmark) y, cada vez más, modelos de IA externos.

Cada uno de estos proveedores procesa datos de los clientes de la SaaS y es, por tanto, subencargado en el sentido del art. 28.2 RGPD. La SaaS debe:

Mantener una lista pública y actualizada de todos los subencargados que utiliza, accesible desde el sitio web (típicamente en una página titulada "Subprocessors" o "Subencargados").
Firmar con cada subencargado un contrato del art. 28 RGPD con garantías equivalentes a las del DPA principal.
Notificar a los clientes con antelación razonable (entre 14 y 30 días suele ser estándar) cualquier cambio significativo: incorporación de un nuevo subencargado, sustitución de uno existente, ampliación del alcance del tratamiento.
Permitir al cliente oponerse al cambio en ese plazo. Si la oposición es justificada y bloquea la continuidad del servicio, el cliente debe tener derecho a rescindir su suscripción.

Encargado vs. responsable independiente: la frontera que más cuesta dibujar

El error más sutil del SaaS en protección de datos es asumir que toda la operativa sobre los datos del cliente se rige por el régimen de encargado. En realidad, hay tres zonas donde la SaaS frecuentemente actúa como responsable independiente y donde el régimen aplicable cambia por completo:

Analítica agregada del producto: si la SaaS cruza datos de uso de todos sus clientes para mejorar el producto, generar benchmarks sectoriales o entrenar modelos de recomendación, esa finalidad es propia de la SaaS, no del cliente. La SaaS se convierte en responsable y necesita base jurídica autónoma (típicamente interés legítimo del art. 6.1.f RGPD, con ponderación documentada), informar a los interesados finales por vía contractual con sus clientes-empresa o anonimizar los datos antes del cruce.
Entrenamiento de modelos de IA: usar los datos de los clientes para entrenar modelos generales que servirán a todos los clientes futuros es claramente una finalidad propia de la SaaS. Sin consentimiento explícito del cliente o sin anonimización irreversible, ese tratamiento no está cubierto por el rol de encargado.
Marketing comercial a los usuarios del producto: si la SaaS envía newsletters, ofertas de upsell o comunicaciones de producto a usuarios individuales que pertenecen a empresas-cliente, está actuando como responsable sobre los datos de esos usuarios concretos, no como encargada sobre los datos de sus empresas.

La forma profesional de gestionar esta zona es:

Mapear con claridad qué tratamientos son de encargado y cuáles de responsable independiente.
Regular cada uno con su propia base jurídica y documentación.
Mencionar explícitamente en el DPA qué tratamientos quedan fuera del rol de encargado y cuáles requieren consentimiento adicional o anonimización previa.
Ofrecer al cliente mecanismos para autorizar o bloquear los tratamientos opcionales (opt-in / opt-out claramente diferenciado).

"En SaaS, el cumplimiento del art. 28 RGPD no es papeleo: es producto. Un DPA accesible, una lista de subencargados pública y una segregación clara de tenants son tres señales que los clientes empresariales miran antes de firmar. Cumplir bien acelera ventas; cumplir mal las bloquea."

Mario P. Talamillo · Socio director, Certix®

Multi-tenant y segregación: la medida de seguridad estructural

Una SaaS atiende a múltiples clientes (tenants) en una misma infraestructura. La forma en que la arquitectura segrega los datos entre tenants es una medida de seguridad estructural del art. 32 RGPD y, en consecuencia, un punto que el DPA debe describir con honestidad técnica:

Multi-tenant lógico con segregación a nivel de aplicación (cada registro lleva un identificador de tenant y el filtrado está aplicado en todas las consultas). Es el modelo más extendido. Requiere extremo cuidado en los tests para que ningún bug permita leakage entre tenants.
Multi-tenant físico con base de datos separada por cliente. Mayor coste operativo pero mejor segregación. Habitual en SaaS de gama alta o sectores muy regulados.
Single-tenant aislado con instancia dedicada por cliente. El extremo opuesto, reservado a clientes muy grandes o regulados.

El cliente empresarial maduro pregunta por este punto antes de firmar. Una SaaS profesional lo documenta en el DPA y en su documentación de seguridad pública.

Brechas: la SaaS es el canal natural de notificación

Cuando ocurre una brecha de seguridad en la SaaS, el régimen del art. 33 RGPD obliga al cliente (responsable) a notificar a la AEPD en menos de 72 horas. Para que esto sea técnicamente posible, la SaaS (encargada) debe avisar al cliente con la mayor rapidez. El DPA debe regularlo:

Plazo de notificación al cliente: típicamente 24-48 horas desde que la SaaS toma conocimiento.
Información mínima de la primera comunicación: naturaleza del incidente, sistemas y categorías de datos afectados, alcance estimado, medidas inmediatas adoptadas.
Colaboración técnica: la SaaS facilita al cliente lo que necesita para preparar la notificación a la AEPD y, en su caso, la comunicación a los afectados.
Comunicación posterior: análisis de causa raíz, plan de mejora, lecciones aprendidas.

Checklist mínimo de una SaaS responsable

DPA estándar publicado, accesible y firmable, alineado con el contenido del art. 28.3 RGPD.
Lista pública de subencargados con identificación, función, país y URL del DPA propio de cada uno.
Mecanismo de notificación de cambios de subencargados a clientes con plazo razonable de oposición.
Mapeo claro entre tratamientos de encargado y de responsable independiente, con bases jurídicas distintas.
Política de uso de IA y entrenamiento: qué datos se usan para mejorar el modelo y bajo qué autorización del cliente.
Documentación pública de seguridad: cifrado, segregación de tenants, certificaciones, recovery point objective.
Procedimiento de notificación de brechas a clientes con plazo expreso.
Funcionalidades en el producto para exportación, supresión y rectificación que faciliten al cliente atender derechos del interesado.
Página pública de privacidad para usuarios del producto (web público, prueba gratuita) que separe claramente del DPA empresarial.

Preguntas frecuentes

¿Una empresa SaaS es responsable o encargada del tratamiento sobre los datos que procesan sus clientes?

La regla general es encargada (art. 28 RGPD) sobre los datos que el cliente sube a la plataforma. Pero la SaaS también actúa como responsable independiente en otras capas: cuenta del administrador, facturación, análisis de uso agregado, mejora del propio servicio. La dualidad debe regularse claramente en los términos de servicio y, sobre todo, en el DPA del art. 28 RGPD que la SaaS firma con cada cliente.

¿Qué debe ofrecer una SaaS a sus clientes para cumplir el art. 28 RGPD?

Un Data Processing Agreement (DPA) que contenga el contenido mínimo del art. 28.3 RGPD: objeto, duración, naturaleza y finalidad, tipos de datos, obligaciones, confidencialidad, medidas de seguridad, subencargados, asistencia para derechos, notificación de brechas y devolución de datos. Suele ofrecerse como anexo de adhesión a los términos del servicio o firmado expresamente.

¿Cuándo deja una SaaS de ser encargada y se convierte en responsable independiente?

Cuando decide por sí misma finalidades nuevas que el cliente no le ha indicado: cruce de datos entre clientes para analítica propia, entrenamiento de modelos de IA generales, reutilización para mejorar el producto comercial más allá de la prestación contratada o marketing a usuarios individuales. En esos casos hace falta base jurídica autónoma, informar a los interesados y cumplir todos los demás deberes del responsable.

¿Tiene una SaaS que ofrecer a sus clientes garantías sobre los subencargados que utiliza?

Sí (art. 28.2 RGPD). La SaaS debe mantener una lista accesible y actualizada de subencargados (AWS, Google Cloud, Cloudflare, Stripe, etc.), firmar con cada uno un contrato del art. 28 RGPD con garantías equivalentes, notificar al cliente los cambios significativos con antelación razonable y permitirle oponerse al cambio. Las grandes plataformas cloud ofrecen sus propios DPA estándar que deben revisarse.

Este contenido es meramente orientativo y divulgativo; no constituye en ningún caso asesoramiento jurídico especializado. La aplicación de la normativa a cada caso concreto requiere análisis individualizado. La normativa autonómica sectorial puede ampliar o modificar plazos y requisitos.

¿Tu SaaS tiene un DPA sólido que aguante el due diligence de clientes empresariales?

En Certix te asignamos un experto en cumplimiento del sector tecnológico. Sin intermediarios comerciales, sin plantillas genéricas.

Hablar con un experto