SLA i SaaS-avtal – tillgänglighet, responstid, RTO, RPO och servicekrediter

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.

Kort svar: Undvik formuleringar som ”hög tillgänglighet” eller ”snabb support”. Skriv i stället mätbara nivåer, tydliga undantag, datakälla för mätningen, incidentklasser, eskalering och konsekvenser vid avvikelse.

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?
SaaS-avtal med SLA GDPR säkerhet och exit

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-avtalet

Vanliga 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.

Tillbaka till blogg