Acuerdo SaaS: ¿qué debe incluir el contrato? 12 cuestiones a regular

Por Mallbutiken · Datos verificados el 1 de octubre de 2026 · Aprox. 9 minutos de lectura

Un buen contrato SaaS describe mucho más que el derecho a utilizar un software. Debe dejar claro en qué consiste el servicio, qué disponibilidad y soporte se prometen, cómo se gestionan los datos del cliente, qué requisitos de seguridad se aplican, de qué son responsables las partes y cómo puede el cliente recuperar sus datos al finalizar el contrato.

¿Qué es un contrato SaaS?

SaaS significa Software as a Service (Software como servicio). El cliente normalmente obtiene acceso a un servicio de software a través de Internet en lugar de comprar una copia tradicional del software. Por lo tanto, el contrato se convierte en una combinación de términos comerciales, derechos de uso, compromisos de operación y soporte, así como reglas para los datos y la seguridad.

No existe ninguna ley sueca específica que establezca por sí sola exactamente cómo debe ser un contrato SaaS B2B. Por lo tanto, el contenido concreto del contrato se vuelve central. Se aplica el derecho contractual general y, dependiendo del servicio, pueden ser relevantes, entre otras cosas, las normas de protección de datos, los derechos de autor, las normas de ciberseguridad y los requisitos sectoriales.

12 preguntas que un contrato SaaS debe responder

1. ¿Qué incluye el servicio? Describa módulos, funciones, número de usuarios, integraciones, almacenamiento, implementación y delimitaciones explícitas.
2. ¿Cuándo se considera entregado el servicio? Si se incluye implementación o migración, deben indicarse los hitos, pruebas y criterios de aceptación.
3. ¿Qué nivel de servicio se aplica? Especifique cómo se mide la disponibilidad, qué excepciones existen y qué sucede en caso de desviaciones recurrentes.
4. ¿Cómo funciona el soporte? Defina canales de contacto, horarios de apertura, niveles de prioridad, tiempo de primera respuesta y escalamiento.
5. ¿Quién tiene derecho a los datos del cliente? Distinga los datos del cliente del software del proveedor, las estadísticas y otros activos intangibles.
6. ¿Cómo se tratan los datos personales? Determine los roles y vincule el PUB/DPA (Acuerdo de Tratamiento de Datos) correcto cuando el proveedor actúa como encargado del tratamiento.
7. ¿Qué requisitos de seguridad se aplican? Haga que los requisitos de acceso, MFA, registro, gestión de vulnerabilidades, copias de seguridad e incidentes sean fáciles de supervisar.
8. ¿Se permite el uso de subcontratistas? Especifique cómo se gestionan los subcontratistas críticos y los posibles subencargados, y cómo se comunican los cambios.
9. ¿Cómo puede cambiar el servicio? Regule los cambios de versión, las funciones descontinuadas y qué ocurre si un cambio afecta sustancialmente el uso del cliente.
10. ¿Cómo funcionan el precio y el ajuste de precios? Especifique la cuota base, las tarifas basadas en el usuario, el consumo excesivo, la indexación, el tiempo de consultoría y cuándo se pueden cambiar los precios.
11. ¿Cómo se distribuye la responsabilidad? Defina errores, subsanación, posibles créditos de servicio, tipos de daños, límites de responsabilidad y excepciones relevantes.
12. ¿Qué sucede cuando finaliza el contrato? Determine de antemano la exportación, el soporte de migración, la eliminación, los plazos y los costes.

SLA: haga que el nivel de servicio sea medible

La "alta disponibilidad" es difícil de verificar. Un Service Level Agreement (Acuerdo de Nivel de Servicio) útil describe qué se mide y cómo. El objetivo de disponibilidad debe combinarse con definiciones para el mantenimiento planificado, errores causados por el cliente y otras excepciones.

El RTO y el RPO se utilizan a menudo para la restauración y la pérdida de datos, pero las cifras deben basarse en el servicio real y las necesidades del cliente. Profundice en esto en la guía sobre SLA, disponibilidad, RTO y RPO.

RGPD: ¿cuándo se necesita un contrato de encargado del tratamiento?

Si el proveedor SaaS trata datos personales por cuenta del cliente, el artículo 28 del RGPD es fundamental. En ese caso, el tratamiento debe regularse mediante un contrato u otro acto jurídico vinculante con la información y las obligaciones que exige el artículo.

Comience con la distribución de roles. El proveedor no es automáticamente un encargado simplemente porque haya datos personales presentes en el servicio. Lea cuándo se necesita un contrato de encargado del tratamiento y qué debe contener. Si existen subencargados o transferencias a terceros países, esas cuestiones también deben abordarse.

Separe la cuestión comercial de los datos del rol de protección de datos

El contrato también debe decir qué puede exportar y utilizar el cliente tras finalizar el contrato. La cuestión comercial sobre el derecho a los datos del cliente no es idéntica a la cuestión del RGPD sobre la responsabilidad del tratamiento de datos personales y la gestión del encargado.

Seguridad: redacte requisitos que se puedan verificar

Adapte el anexo de seguridad según la sensibilidad de los datos y la importancia crítica para el negocio. Ejemplos de áreas concretas son la gestión de identidades y permisos, MFA, cifrado, registro, gestión de vulnerabilidades y parches, desarrollo seguro, copias de seguridad, comunicación de incidentes y continuidad.

Para las empresas cubiertas por la ley de ciberseguridad, la cadena de suministro es explícitamente una de las áreas que las medidas de seguridad deben cubrir como mínimo. Por lo tanto, un contrato con el proveedor puede ser una herramienta importante para establecer requisitos y hacerles seguimiento, pero el contrato no sustituye la gestión de riesgos propia. Lea también la guía sobre NIS2 y requisitos de seguridad en los contratos con proveedores.

Planifique la salida cuando la relación aún funciona

A menudo es caro empezar a discutir sobre la exportación de datos solo cuando las partes quieren separarse. Por lo tanto, regule la salida desde el momento de la firma del contrato.

• ¿Qué formato de exportación recibe el cliente?
• ¿Se incluyen metadatos, configuración y archivos adjuntos?
• ¿Durante cuánto tiempo es posible exportar tras la rescisión?
• ¿Puede el cliente utilizar una API para la migración?
• ¿Qué soporte de migración se incluye y cuánto cuesta el trabajo adicional?
• ¿Cuándo se eliminan los datos de producción, datos de prueba y copias?
• ¿Puede el proveedor entregar un certificado de eliminación?

Una buena cláusula de salida reduce el bloqueo (vendor lock-in) y hace que sea más fácil comparar proveedores incluso antes de la compra. Profundice en el área en SaaS exit y migración de datos – lista de verificación contractual, que repasa formatos de exportación, API, metadatos, soporte de migración, copias de seguridad y eliminación.

Límites de responsabilidad: vincule el nivel al riesgo real

No existe un porcentaje universal que sirva para todos los negocios SaaS. Un límite de responsabilidad razonable depende, entre otras cosas, del valor del contrato, la sensibilidad de los datos, la dependencia operativa, los seguros y los posibles daños consecuentes. Verifique también qué eventos quedan fuera del límite y si la limitación de responsabilidad interactúa con créditos de servicio, confidencialidad, datos personales y propiedad intelectual.

El artículo 36 de la Ley de Contratos permite ajustar o dejar sin efecto condiciones contractuales injustas, pero no sustituye la negociación de una distribución de riesgos bien pensada desde el principio.

Lista de verificación antes de firmar

• ¿Están documentados el alcance del servicio y todas las excepciones importantes?
• ¿Se pueden medir los valores del SLA con datos que ambas partes puedan verificar?
• ¿Son claros los canales de soporte y de incidentes?
• ¿Se han evaluado los roles de datos personales, subencargados y flujos internacionales?
• ¿Los requisitos de seguridad coinciden con el riesgo del servicio y los posibles requisitos sectoriales del cliente?
• ¿Son predecibles los cambios de precio y el consumo excesivo?
• ¿Son claras las reglas para las funciones cambiantes?
• ¿Se han elegido conscientemente los límites de responsabilidad y las excepciones?
• ¿Se pueden exportar los datos del cliente en la práctica?
• ¿Están coordinadas la rescisión, la suspensión y la salida?

¿Necesitan un conjunto de documentos contractuales completo?

El contrato SaaS para B2B de Mallbutiken contiene un contrato principal y seis anexos para, entre otras cosas, especificación del servicio, SLA, PUB/RGPD, seguridad, salida y precio. Se entrega en Word y PDF editables. Precio en tienda: 149 SEK.

Ver la plantilla de contrato SaaS

Preguntas frecuentes

¿Es un contrato SaaS lo mismo que un contrato de licencia?

No necesariamente. Un contrato SaaS normalmente también necesita gestionar el servicio en curso, la operación, el soporte, los datos, la seguridad y la salida. La parte de la licencia es solo una parte de la relación.

¿Debe ser escrito un contrato SaaS B2B?

No existe un requisito de forma general para todos estos contratos, pero un contrato escrito es importante para poder demostrar el alcance del servicio y la distribución de riesgos. Partes específicas pueden estar cubiertas por sus propios requisitos, como la exigencia del RGPD de una regulación vinculante del tratamiento por cuenta de terceros.

¿Puede el proveedor cambiar funciones durante el periodo del contrato?

Depende del contrato. Por lo tanto, regule el derecho a modificar, cómo se informa al cliente y qué ocurre si una función esencial se elimina o cambia.