SLA SaaS Germany: Contract Design Guide | IT-Medienrecht

These examples illustrate a possible scheme, often categorized as P1/P2/P3. Importantly, the SLA should define when the clock runs. Response times often only apply within defined support hours, such as Monday to Friday, 8:00-18:00.

For example, a "response time 1 hour" under business hours conditions means a critical fault reported at 10 p.m. on Friday does not need processing until 9 a.m. on the next working day. If 24/7 support is offered, it must be explicitly agreed upon, often incurring additional costs for startups. Alternatively, providers can offer premium support with extended hours for an extra charge.

In addition to response time, a solution time (time-to-resolve) is sometimes agreed. For instance, for P1 faults, a solution or at least a workaround might be required within 4 or 8 hours. However, this can be challenging as not every error can be resolved within a fixed timeframe. Often, defining response or recovery times as targets (service level objectives) without strict guarantees is sufficient. It is crucial that support processes are clearly described, including how customers report faults (e.g., ticket system, hotline) and how these are prioritized. A transparent process enhances customer confidence and manages expectations effectively.

Contractual Penalties and Credits for SLA Violations

No SLA is complete without provisions on what happens if the provider fails to meet the promised service levels. This is where contractual sanctions come into play, ranging from contractual penalties to service credits. In the SaaS environment, service credits have become a common solution. These act as a kind of money-back guarantee in the form of a credit note, which the customer can request if the SLA is not met.

Typical Models for Service Credits

Providers and customers often agree on a certain percentage of the monthly fee to be credited, depending on how severely the SLA was missed. For example: If guaranteed availability is not met, the provider grants a credit of y% of the monthly fee for every x hours of downtime.

A concrete model from practice: "For every 30 minutes of downtime or part thereof, the customer receives a credit note in the amount of one day's rent (1/30 of the monthly fee), up to a maximum of 50% of the monthly fee." This represents a flat-rate compensation. The customer receives financial compensation (usually offset against future invoices) without having to provide complicated proof of individual damages. At the same time, the provider limits its liability (e.g., to a maximum of half of one month's remuneration). This model aims to create an incentive for performance without excessively penalizing the provider.

Limits of Service Credits

It is important that such credits are granted automatically or upon simple request from the customer. There is usually a deadline within which the customer must report the SLA breach and claim the credit. For example: "within 5 working days of the end of the month." If the customer misses this deadline, the claim expires, which should be clearly stated in the contract. Cash payment of credits is typically excluded; instead, they are offset against future payments.

Additionally, many SLAs stipulate that Service Credits are the customer's exclusive remedy. This means they are granted instead of other warranty or compensation claims. In this way, the provider attempts to prevent the customer from asserting further claims, such as loss of profit, despite the credit. However, caution is advised: This limitation of liability must be permissible under German law (see next section).

Contractual Penalty vs. Liquidated Damages

In legal terms, service credits are a form of liquidated damages or contractual penalty, depending on their structure. A contractual penalty ("contractual penalty") primarily has a sanctioning character. It pressures the provider to fulfill obligations and simplifies compensation for the customer without needing proof of actual damage.

In contrast, genuine lump-sum compensation mainly facilitates proof and is based on typical damages. In practice, the terms can blur. "Service credits" are often used to make the concept sound customer-friendly, but ultimately, it is a contractually agreed compensation for reduced performance. Important: The amount and conditions of the credits should be clearly defined in the contract, preferably objectively measurable (e.g., percentages, times).

No provider will agree to an unlimited penalty payment. This is why caps (ceilings) are common, such as 50% of the monthly fee in the example above. Special termination rights can also be agreed. In the event of serious SLA violations (e.g., availability falls far below the promised level for an extended period), the customer gains the right to terminate the contract without notice for good cause. This "exit clause" may seem dramatic, but it is an important means of exerting pressure and increases the credibility of the SLA.

Admissibility Under GTC Law and Limitation of Liability in SLAs

For German SaaS startups, it is crucial that SLA clauses comply with the law on general terms and conditions (Sections 305 et seq. BGB). SLAs are usually regarded as prefabricated contractual terms. A seemingly clever clause is useless if it is ineffective in court.

The following points should be observed:

Key Considerations for GTC Compliance

• No "Surprising" Clauses: Contract terms that are so unusual that the customer could not reasonably have expected them are not part of the contract (Section 305c BGB). Therefore, important SLA and liability clauses should be formulated transparently and clearly, not hidden in small print.
• Do Not Exclude Liability for Gross Negligence: The exclusion or limitation of liability for intent and gross negligence is not permitted in GTCs. Damages resulting from injury to life, limb, or health and liability for fraudulent intent also may not be excluded. Such exclusions of liability would be unreasonably disadvantageous (Section 307 BGB) and therefore invalid. An SLA clause must never imply that the provider is not liable even in cases of intent or gross negligence, as this would not be legally tenable.
• Use "Guarantee" with Caution: If a service is expressly promised as a guarantee in the SLA, liability cannot be limited by other clauses in the event of non-compliance. Example: If the provider "guarantees that availability is 99.9%," this could be interpreted as an independent guarantee obligation. In such a case, statutory guarantee liability (Section 444 BGB analogously) applies, and an exclusion of liability for this would be ineffective. Legal experts therefore recommend using terms such as "assure" or "agree" instead. Explicitly regulate the legal consequences of non-compliance in the SLA (e.g., through service credits), rather than carelessly using the word "guarantee."
• Liability for Slight Negligence: In cases of simple (slight) negligence, liability can generally be limited in general terms and conditions, but not unlimited. Cardinal obligations are essential contractual obligations whose breach would jeopardize the achievement of the contract's purpose. If the provider breaches such cardinal obligations, case law requires that they must at least compensate for the foreseeable damage typical for the contract. A complete exclusion of liability for slight negligence concerning essential services (like the main service of SaaS provision) does not withstand a GTC review. This means, for instance, that a clause like "In the event of service failure, any liability of the provider is excluded" would be invalid. The customer would be entitled to compensation for typical damages (e.g., rent reduction) in an emergency, despite the GTC. However, it is permissible to limit the amount of liability (e.g., to a certain amount or to the sum of fees paid), provided that core obligations are not completely excluded from liability.
• No Blanket Exclusions for Certain Types of Damage: Providers often try to generally exclude liability for indirect damages, loss of profit, business interruption, or loss of data in general terms and conditions. However, such blanket exclusions are legally risky. Under German law, they can be considered unreasonable, especially if they concern typically expected damages. For example, a complete exclusion for data loss is problematic if the SaaS provider owes data security by contract. A total exclusion of liability would disadvantage the customer unreasonably. It is better to limit liability for such consequential damages to intent and gross negligence, but not to exclude liability for all negligence. Additionally, customers should be contractually informed of backup obligations to ensure a fair distribution of risk (topic: data backup).
• Keep Contractual Penalties Moderate: If a contractual penalty is agreed in the SLA for violations, such as a fixed amount of money per hour of downtime, this must be reasonable. In consumer contracts, contractual penalties in general terms and conditions are generally not permitted under Section 309 No. 6 BGB. They are permitted in B2B contracts, but the amount is subject to limits. The BGH has ruled that contractual penalties agreed in GTCs exceeding 5% of the contract value are generally invalid. This means a clause awarding the SaaS customer, for example, 10% of the monthly fee as a penalty per hour of downtime, would exceed this threshold and could be unenforceable. Therefore, if penalties are to be imposed, they should be low and ideally negotiated individually, rather than set too high in the GTC.
• Reduction in Rent and Statutory Warranty: As SaaS is often legally classified as a rental agreement (provision of software for a fee), the customer is generally entitled to a reduction in rent for defects according to Section 536 BGB. If the software is unavailable (downtime exceeding contractually permissible levels), this could be considered a rental defect, potentially leading to a reduction in fees or even compensation. Many providers try to replace this statutory right to reduce fees with the SLA provision. For example, by stipulating that service credits are the customer's exclusive entitlement. However, such a clause must be drafted carefully so that it does not unreasonably disadvantage the customer (Section 307 BGB). Practically, this means the compensation in the SLA (credits) should roughly correspond to the value of the statutory reduction. If the contractual credit is much lower than what the customer could demand by law, the clause risks invalidity. In cases of doubt, the customer should at least reserve the right to claim further damages if the actual damage exceeds the flat-rate credit, at least for cases where the provider is responsible. Careful legal wording is highly recommended here.

In summary, a legally compliant SLA design must balance clearly defined commitments, which are helpful for customers, with effective limitations of liability for the provider. Surprises and one-sidedness must be avoided. When in doubt, SLA clauses should remain simple and fair to ensure they hold up in an emergency and are not overturned in court.

Conclusion

A well-formulated SLA is invaluable for a SaaS startup. It builds trust with customers by reliably promising availability, support, and response times. At the same time, it provides the provider with a clear framework for risk control.

Standard market availability commitments, such as 99% or 99.9% uptime, assure customers of service reliability. Clearly defined maintenance windows give operators necessary flexibility for updates without hidden downtimes. Graduated support levels with swift response times for critical issues demonstrate professionalism and customer focus. In the worst-case scenario, service credits offer contractual compensation, ensuring customers are fairly remunerated without resorting to legal action. This holistic approach fosters professional customer communication and predictably limits the provider's liability.

When drafting an SLA, startups must always consider the legal framework. An excellent SLA clause is useless if it doesn't hold up in court. Adhering to the legal guidelines for general terms and conditions – avoiding inadmissible liability exclusions and ensuring appropriate regulations for duty breaches – makes the SLA legally secure. When in doubt, seeking legal advice or referencing established industry models is advisable.

Ultimately, an SLA is more than just a contract; it is a performance promise to the customer. When done well, both parties benefit: customers know what they can rely on, and the startup sets clear boundaries for its obligations. This ensures reliable collaboration, prevents disputes, and allows the SaaS startup to focus on continuous service improvement without getting entangled in liability complexities. A clear SLA design yields long-term benefits in both customer satisfaction and legal certainty.