SLA (Service Level Agreement): legal obligations and how to draft one

What is an SLA and what is its purpose in SaaS?

The Service Level Agreement (SLA) sets measurable service levels (KPIs) that the provider commits to delivering: availability, response and restoration times, support, security, backups and exit portability. It is generally attached to a SaaS licence agreement or the applicable terms of sale/use. Unlike an SOW (Statement of Work), it governs ongoing service performance, not a one-off deliverable. For a brief overview of the concept, see this industry introduction (Advancia Teleservices).

Legal framework in France and the EU

Contract law (Civil Code)

No French law requires an SLA. Legally, it is a contractual commitment subject to the general rules on obligations: freedom of contract (art. 1101 C. civ.), remedies for non-performance (art. 1217), force majeure (art. 1218 C. civ.), and review of a penalty clause (clause pénale) (art. 1231-5 C. civ.), which a court may reduce if manifestly excessive (Justice.fr). Also watch art. 1170 C. civ.: a clause depriving an essential obligation of its substance (e.g. an SLA neutralised by a derisory liability cap) is deemed unwritten.

Data protection (GDPR)

If the service processes personal data, the SLA must be consistent with the GDPR processing agreement (art. 28 of the GDPR): security (with ISO 27001 as a reference), incident management, notification deadlines and exit portability. In practice, a detailed DPA supplements the SLA; see our DPA guide for SaaS and CNIL recommendations (e.g. notification of a breach to the authority within 72 hours and to the client controller without undue delay).

Digital and cloud services

Certain SaaS offerings that may qualify as intermediary services must also consider the transparency obligations under the Digital Services Act (EU 2022/2065) when hosting third-party content. For cloud contractual arrangements, the EDPS guidelines emphasise data location, exit portability and the processing chain. Useful guidance is also available from the French administration (Economie.gouv.fr) and business guidance sheets (Service Public Pro).

For an industry perspective on cloud contracting practices and common pitfalls, see this analysis too (IT for Business).

How to draft a robust SLA: method and key clauses

1) Scope, definitions and contractual structure

• Precisely document covered services (modules, APIs, deployment regions), environments (production/pre-production) and exclusions.
• Standardised definitions: Availability, GTI (response times), GTR (restoration times), P1/P2/P3 (severity), RPO (permissible data loss), RTO (recovery time).
• Document hierarchy: in a conflict, order of precedence between the main agreement, SLA, DPA, SaaS terms of sale and technical policies.

2) KPIs and measurable service levels

• Monthly availability (e.g. 99.9%). Typical formula: Availability (%) = (Total minutes – unplanned downtime) / Total minutes × 100. Exclude scheduled maintenance and force majeure events (art. 1218 C. civ.).
• Support: P1 GTI ≤ 30 min 24/7, P2 ≤ 2 hours, channels (ticketing, telephone), on-call coverage.
• Restoration: P1 GTR ≤ 4 hours or a workaround; P2 ≤ 1 business day.
• Performance: API response time p95 ≤ 300 ms, error rate p95 ≤ 0.1%.
• Backups: RPO ≤ 24 hours, quarterly restoration tests, 30-day retention.
• Security: encryption at rest/in transit, admin MFA, monthly access reviews, 180-day logging, vulnerability management (patch SLA).

3) Measurement, evidence and reporting

• Measurement window: monthly, by time zone and region.
• Measurement sources: internal tools (logs, APM) and/or third parties. Retain logs for 12 months.
• Reports: self-service dashboard + monthly report sent to the client.
• Audit: reasonable audit right, combined with certification reports (ISO/IEC 27001, ISO/IEC 20000-1).

4) Incident management and escalation

• Clear classification (P1 total unavailability, P2 major degradation, etc.).
• Escalation process: time limits, roles, on-call coverage, contact points, real-time status (status page).
• Written post-mortem for every P1, action plan and follow-up.

5) Security, GDPR and notifications

• Security incident notification: without undue delay and within a maximum of 24 hours for potential personal data leaks, to enable compliance with the 72 hours provided for by the GDPR/CNIL.
• Processing chain: approval/advance notice for every new processor, consistent with the DPA (art. 28 GDPR).
• Tests and audits: regular scans, annual penetration tests, fixes according to severity (e.g. critical ≤ 7 days).

To support this component, see our DPA guide and the EDPS cloud recommendations (guidelines).

6) Business continuity and exit portability

• Disaster recovery plan (PRA): RTO/RPO objectives, documented tests, responsibilities.
• Exit portability: data export (open formats), assistance, deadlines and capped costs.

7) Service credits, penalties and their relationship with liability

• Service credits: automatic discounts for failure to meet targets (e.g. 10% if availability < 99.9%). They must not deprive the client of other remedies (art. 1170 C. civ.).
• Penalty clause: possible, but a court may reduce it if excessive (art. 1231-5 C. civ.). Prefer proportionate, capped schedules.
• Limitation of liability: adjust the cap so it does not neutralise the SLA. See our guidance on the limitation of liability clause.

8) Exclusions and maintenance

• Scheduled maintenance: announced windows (e.g. Sunday 2–4 a.m. CET), limited and outside business hours where possible.
• Exclusions: force majeure events (art. 1218 C. civ.), client faults or environments, failures at third parties not engaged as subcontractors, massive DDoS attacks if contractual protections have not been purchased.

To calibrate these exclusions legally, revisit your force majeure and hardship clauses.

9) Governance, review and changes

• Quarterly steering committee, KPI monitoring and improvement plans.
• Annual review of the SLA (60 days' notice, right to terminate for substantial degradation).
• Versioning: change management, traceability, written notification.

Sample availability and service credit schedule

• ≥ 99.9%: compliant (no credit)
• [99.0%; 99.9%): credit of 10% of the affected monthly invoice
• [98.0%; 99.0%): 25% credit
• < 98.0%: 50% credit + right to terminate without fees if this occurs for 2 consecutive months

Specify the request procedure (automatic versus on claim) and that credits cannot be combined with other discounts. Avoid describing credits as the “sole and exclusive remedy” to avoid conflict with art. 1170 C. civ..

Common mistakes to avoid

• Unmeasurable or poorly defined KPIs (no formula or measurement window).
• No coordination with liability: a cap that is too low may neutralise the SLA.
• Overly broad exclusions (everything becomes “maintenance” or “force majeure”).
• No 24/7 P1 escalation or post-mortem.
• Forgetting exit portability and the GDPR processing chain.

Quick SLA checklist

• Clear scope, definitions and document hierarchy
• Numerical KPIs: availability (≥99%), GTI/GTR, performance, backups
• Measurement, monthly reporting and audit
• Incident management, escalation, post-mortem
• Security, DPA and GDPR notifications aligned with CNIL guidance
• Proportionate credits/penalties (art. 1231-5)
• Documented exclusions and maintenance
• Exit portability, disaster recovery plan (RTO/RPO), processors
• Annual review and termination right for repeated breaches

Clause extracts (examples to adapt)

Availability

“The Provider guarantees monthly Service availability of 99.9%. Availability is calculated as follows: (Total minutes in the month – Unplanned downtime) / Total minutes × 100. Duly notified scheduled maintenance downtime and force majeure events within the meaning of art. 1218 C. civ. are excluded.”

Service credits

“If a Service Level is not met, the Client receives a credit as defined in the schedule above, applied to the following monthly invoice. These credits do not affect the Client's right to seek other remedies provided by law or the Agreement where non-performance causes separate loss.”

GDPR notifications

“The Provider shall notify the Client without undue delay and no later than twenty-four (24) hours of any Security Incident likely to affect Personal Data, enabling the Client to meet its notification obligations under the GDPR and CNIL guidelines.”