SaaS agreement – what should the agreement include? 12 questions to regulate

By Mallbutiken · Facts checked September 30, 2026 · Approx. 9 minutes read

A good SaaS agreement describes more than just the right to use software. It should clearly state what the service includes, the uptime and support promised, how customer data is handled, what security requirements apply, the parties' respective responsibilities, and how the customer can retrieve their data when the agreement ends.

What is a SaaS agreement?

SaaS stands for Software as a Service. Customers typically gain access to a software service via the internet rather than purchasing a traditional copy of the software. The agreement, therefore, becomes a combination of commercial terms, usage rights, operations and support commitments, and rules concerning data and security.

There is no specific Swedish law that exclusively dictates exactly how a B2B SaaS agreement should look. Therefore, the concrete content of the agreement is central. General contract law applies, and depending on the service, data protection regulations, copyright, cybersecurity rules, and sectoral requirements may also be relevant.

12 questions a SaaS agreement should answer

1. What is included in the service? Describe modules, features, number of users, integrations, storage, implementation, and explicit exclusions.
2. When is the service considered delivered? If implementation or migration is included, milestones, testing, and acceptance criteria should be specified.
3. What service level applies? Specify how availability is measured, what exceptions exist, and what happens in the event of recurring deviations.
4. How does support work? Define contact channels, business hours, priority levels, initial response times, and escalation procedures.
5. Who owns the customer data? Distinguish between customer data and the supplier's software, statistics, and other intellectual property.
6. How is personal data processed? Determine roles and link the correct DPA (Data Processing Agreement) when the supplier acts as a data processor.
7. What security requirements apply? Make requirements for access, MFA, logging, vulnerability management, backup, and incidents verifiable.
8. Can subcontractors be used? Specify how critical subcontractors and any sub-processors are managed and how changes are communicated.
9. How may the service be changed? Regulate version changes, discontinued features, and what applies if a change significantly affects the customer's use.
10. How do pricing and price adjustments work? State base fees, user-based fees, overages, indexation, consulting rates, and when prices may change.
11. How is liability allocated? Define faults, remedies, service credits (if applicable), types of damages, liability caps, and relevant exclusions.
12. What happens when the agreement ends? Determine export procedures, migration support, deletion, deadlines, and costs in advance.

SLA: making service levels measurable

"High availability" is difficult to verify. A useful Service Level Agreement describes what is measured and how. The availability target needs to be combined with definitions for planned maintenance, customer-caused errors, and other exceptions.

RTO and RPO are often used for recovery and data loss, but these figures should be based on the actual service and the customer's needs. Do not include ambitious values that no technical solution can meet.

GDPR: when is a data processing agreement (DPA) needed?

If the SaaS supplier processes personal data on the customer's behalf, Article 28 of the GDPR is central. In such cases, the processing must be regulated through an agreement or other binding legal act containing the information and obligations required by the article.

Start with role allocation. The supplier is not automatically a processor just because personal data appears in the service. Read about when a data processing agreement is needed and what it should contain. If sub-processors or third-country transfers occur, those issues must also be addressed.

Separate commercial data issues from data protection roles

The agreement should also specify what the customer is entitled to export and use after the agreement ends. The commercial question regarding rights to customer data is not identical to the GDPR question regarding data responsibility and processing.

Security: write requirements that can be verified

Adjust the security appendix based on data sensitivity and operational criticality. Examples of concrete areas include identity and access management, MFA, encryption, logging, vulnerability and patch management, secure development, backup, incident communication, and business continuity.

For businesses subject to the Cybersecurity Act, the supply chain is explicitly one of the areas that security measures must at least address. A supplier agreement can therefore be an important tool for setting requirements and following them up, but the agreement does not replace your own risk management. Also read the guide on NIS2 and security requirements in supplier agreements.

Plan your exit while the relationship still works

It is often expensive to start discussing data export only when the parties want to part ways. Therefore, regulate the exit process at the time of entering the agreement.

• What export format does the customer receive?
• Are metadata, configurations, and attachments included?
• How long is export possible after termination?
• Can the customer use an API for migration?
• What migration support is included, and what are the costs for extra work?
• When are production data, test data, and copies deleted?
• Can the supplier provide a certificate of deletion?

A good exit clause reduces vendor lock-in and makes it easier to compare suppliers even before purchase.

Liability caps: link the level to actual risk

There is no universal percentage that fits all SaaS deals. A reasonable liability cap depends on factors such as contract value, data sensitivity, operational dependence, insurance, and potential consequential damages. Also, check which events are excluded from the cap and whether the limitation of liability aligns with service credits, confidentiality, personal data, and intellectual property rights.

Section 36 of the Swedish Contracts Act provides the possibility to adjust or set aside unfair contract terms, but this is no substitute for negotiating well-considered risk allocation from the start.

Checklist before signing

• Are the scope of the service and all important exclusions documented?
• Can the SLA values be measured using data that both parties can verify?
• Are support and incident channels clear?
• Have personal data roles, sub-processors, and international transfers been assessed?
• Do security requirements match the service's risk and any sector-specific requirements?
• Are price changes and overages predictable?
• Are the rules for changing features clear?
• Are liability caps and exclusions chosen deliberately?
• Is customer data exportable in practice?
• Are termination, suspension, and exit processes coordinated?

Do you need a complete agreement template?

Mallbutiken's B2B SaaS agreement includes a master agreement and six appendices covering areas such as service specifications, SLA, GDPR/DPA, security, exit, and pricing. Delivered in editable Word and PDF formats. Price in store: 149 SEK.

See the SaaS agreement template

Frequently asked questions

Is a SaaS agreement the same as a license agreement?

Not necessarily. A SaaS agreement normally also needs to handle the ongoing service, operations, support, data, security, and exit. The license component is only one part of the relationship.

Must a B2B SaaS agreement be written?

There is no general formal requirement for all such agreements, but a written agreement is important to be able to demonstrate the scope of the service and risk allocation. Specific parts may be subject to their own requirements, such as the GDPR's requirement for binding regulation of data processing.

Can the supplier change features during the agreement period?

That depends on the agreement. Therefore, regulate the right to change, how the customer is informed, and what happens if an essential feature is removed or altered.