SLA i SaaS-avtal – tillgänglighet, responstid, RTO, RPO och servicekrediter
Dela
Av Mallbutiken · Sakuppgifter kontrollerade 30 september 2026 · Cirka 8 minuters läsning
Ett SLA gör SaaS-leverantörens servicenivå mätbar. Det bör definiera vad tillgänglighet betyder, hur den beräknas, hur incidenter prioriteras, vilka responstider som gäller, vilka återställningsmål som är relevanta och vad kunden får om servicenivån inte uppnås.
Vad är ett SLA i ett SaaS-avtal?
SLA står för Service Level Agreement och är ofta en bilaga till huvudavtalet. Huvudavtalet beskriver den kommersiella relationen, medan SLA:n preciserar den löpande tjänstens mätbara kvalitetsnivåer.
Ett bra SLA ska kunna användas både under normal drift och när något går fel. Om parterna först vid en incident börjar diskutera vad ”kritisk störning” eller ”99,9 procent tillgänglighet” betyder är avtalet för otydligt.
Se även huvudguiden om vad ett SaaS-avtal bör innehålla.
Tillgänglighet – procenttalet är bara början
En tillgänglighetsnivå, exempelvis 99,9 procent, säger lite utan mätregler. Ange därför:
- vilken tjänst eller vilka komponenter som omfattas,
- mätperiod, exempelvis kalendermånad,
- vilken datakälla som används,
- när nedtid börjar och slutar,
- om planerat underhåll räknas bort,
- hur kundorsakade fel eller force majeure behandlas,
- om prestandaförsämring kan räknas som otillgänglighet.
Skillnaden mellan 99,9 och 99,99 procent kan vara kommersiellt stor. Kravet bör därför bygga på hur verksamhetskritisk tjänsten är och vad leverantörens tekniska arkitektur faktiskt kan leverera.
| Mätpunkt | Fråga att besvara |
|---|---|
| Tillgänglighet | Vilken procentnivå, period och komponent gäller? |
| P1/P2/P3 | Hur definieras kritisk, hög och normal incident? |
| Responstid | När ska leverantören ha påbörjat kvalificerad hantering? |
| Återställning | Finns mål för återställning av tjänst och data? |
| Kommunikation | Hur ofta ska kunden få statusuppdatering? |
| Påföljd | När utgår servicekredit eller annan rättighet? |
Incidentklasser och responstid
Incidentklassificeringen bör utgå från påverkan, inte bara teknisk feltyp. Ett fel kan vara tekniskt begränsat men affärskritiskt om det exempelvis blockerar betalningar eller åtkomst till en central process.
För varje prioritetsnivå kan SLA:n ange första responstid, måltid för workaround eller återställning, uppdateringsfrekvens och eskaleringsnivå. Var noga med skillnaden mellan responstid och lösningstid. Ett svar inom 30 minuter betyder inte automatiskt att felet ska vara löst inom 30 minuter.
Supportfönster måste matcha verksamheten
En P1-responstid på 30 minuter är värdelös för en verksamhet som kör dygnet runt om leverantörens support bara är öppen vardagar 09–17. Ange vilka nivåer som gäller utanför ordinarie supporttid och hur kritiska incidenter rapporteras.
RTO och RPO – två olika återställningsmål
RTO används som mål för hur snabbt en tjänst eller process behöver kunna återställas efter ett avbrott. RPO används som mål för hur stor dataförlust bakåt i tiden som kan tolereras i en återställningssituation.
De bör inte väljas isolerat i IT-avtalet. En BIA kan visa hur länge verksamheten faktiskt klarar ett avbrott och vilken dataförlust som är acceptabel. Läs guiden om Business Impact Analysis och det praktiska BIA-exemplet.
Kontrollera också vad leverantören menar med sina värden. Är RTO ett mål, en garanti eller endast en intern designprincip? Gäller RPO alla datatyper? Hur ofta testas återställningen?
Servicekrediter – kompensation eller enda påföljd?
Servicekrediter kan skapa ett automatiskt ekonomiskt incitament när servicenivån missas. En trappa kan exempelvis ge större kredit ju längre under målnivån tjänsten hamnar.
Men kontrollera om avtalet säger att servicekredit är kundens enda påföljd. Vid allvarliga eller återkommande brister kan kunden behöva andra rättigheter, exempelvis rätt till åtgärdsplan, särskild eskalering eller uppsägning. Samordna SLA:n med huvudavtalets ansvarsbegränsning och uppsägningsregler.
Planerat underhåll och andra undantag
Leverantören behöver normalt kunna underhålla tjänsten, men ett för brett undantag kan göra tillgänglighetsmålet missvisande. Reglera hur långt i förväg underhåll ska meddelas, vilka tidsfönster som får användas och om akut säkerhetsunderhåll hanteras annorlunda.
Var också försiktig med undantag för tredjepartstjänster. Om leverantören själv valt en kritisk moln- eller infrastrukturleverantör bör avtalet tydliggöra hur beroendet påverkar SLA och ansvar.
Checklista för ett användbart SLA
- Är den mätta tjänsten tydligt definierad?
- Finns en entydig formel för tillgänglighet?
- Är planerat underhåll avgränsat?
- Är incidentnivåerna kopplade till verksamhetspåverkan?
- Skiljer avtalet på respons, workaround och lösning?
- Fungerar supporten under era kritiska driftstider?
- Är RTO/RPO kopplade till verkliga kontinuitetsbehov?
- Finns krav på statusuppdatering under P1-incidenter?
- Är servicekrediter och andra påföljder tydliga?
- Finns rätt att agera vid upprepade SLA-brott?

Behöver ni huvudavtal och SLA i samma struktur?
Mallbutikens SaaS-avtal innehåller huvudavtal och sex bilagor för bland annat tjänstespecifikation, SLA, PUB/GDPR, säkerhet, exit och pris. Word och PDF. Pris i butiken: 149 kr.
Se SaaS-avtaletVanliga frågor
Är 99,9 procent alltid ett bra SLA?
Nej. Rätt nivå beror på tjänstens kritikalitet, mätmetod, undantag och kostnaden för högre redundans. Procenttalet måste sättas i sitt sammanhang.
Är RTO samma sak som SLA-tillgänglighet?
Nej. Tillgänglighet mäter normalt drift över en period. RTO handlar om målet för återställning efter ett avbrott.
Bör servicekredit vara den enda påföljden?
Det är en avtalsfråga, men kunden bör medvetet bedöma om enbart kredit är tillräckligt vid allvarliga eller upprepade brister.
Relaterad vägledning
Läs SaaS-avtalsguiden, NIS2 och leverantörssäkerhet och kontinuitetsplan-guiden.
Källor och vidare läsning
Guiden ger generell information. SLA-nivåer bör anpassas efter tjänstens arkitektur, verksamhetskritikalitet och övriga avtalsvillkor.