SLA för molntjänster: så granskar du avtalet rätt
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
SLA för molntjänster: så granskar du avtalet rätt
Ett servicenivåavtal (SLA) för molntjänster är inte bara juridik — det är den operativa grundplåten som avgör vad som händer när saker går fel. Ett välförhandlat SLA definierar mätbara krav på upptid, prestanda och säkerhet, reglerar kompensation vid avbrott och tvingar leverantören att dokumentera sin incidentprocess. Ändå ser vi på Opsios NOC regelbundet kunder som köpt molntjänster utan att ha läst eller förstått sitt SLA.
Viktiga slutsatser
- Ett SLA utan tydliga definitioner av upptid, mätmetod och kompensation är i praktiken värdelöst. Ord som "hög tillgänglighet" utan siffror ger dig noll hävstång.
- Datasäkerhet regleras sällan tillräckligt i standard-SLA:er — du måste förhandla om kryptering, åtkomstkontroll och incidentrespons.
- GDPR och NIS2 ställer krav som ditt SLA måste spegla, oavsett var leverantören har sitt huvudkontor.
- Servicekrediter låter bra men täcker sällan den verkliga kostnaden av ett avbrott — kräv eskaleringsmekanismer och ansvar.
- Exit-klausuler och dataportabilitet avgör om du kan byta leverantör utan att förlora kontrollen.
Vad ett SLA för molntjänster faktiskt ska innehålla
Många organisationer behandlar SLA:et som en formalitet — ett dokument som signeras och arkiveras. Det är ett misstag. Ett SLA är det enda verktyg du har för att hålla din leverantör ansvarig. Här är de delar som måste finnas med, och vad vi ser saknas i praktiken.
Definitioner och omfattning
Varje SLA börjar med definitioner, och det är här de flesta problem uppstår. Termen "upptid" kan betyda vitt skilda saker beroende på leverantör. AWS definierar exempelvis "Monthly Uptime Percentage" som andelen minuter regionen är tillgänglig, exklusive schemalagt underhåll. Azure har en liknande men inte identisk definition.
Du behöver entydiga svar på:
- Hur mäts upptid? Per region, per tjänst, per enskild resurs?
- Vad räknas som nedtid? Är degraderad prestanda detsamma som otillgänglighet?
- Vilka undantag gäller? Schemalagt underhåll, force majeure, kundens egen konfiguration?
- Vilka tjänster omfattas? Ett SLA som täcker compute men inte nätverk eller lagring lämnar stora luckor.
Tillgänglighet och upptidsgarantier
Siffror som 99,9 % och 99,99 % ser nästan identiska ut men innebär dramatiskt olika saker i praktiken:
| Upptidsnivå | Tillåten nedtid per år | Tillåten nedtid per månad | Typisk användning |
|---|---|---|---|
| 99 % | ~3,65 dagar | ~7,3 timmar | Utvecklingsmiljöer |
| 99,9 % | ~8,76 timmar | ~43 minuter | Standard produktion |
| 99,95 % | ~4,38 timmar | ~22 minuter | Affärskritiska system |
| 99,99 % | ~52 minuter | ~4,3 minuter | Finansiella tjänster, hälsovård |
| 99,999 % | ~5,26 minuter | ~26 sekunder | Sällan garanterat av en enskild leverantör |
En viktig insikt från Opsios drift: den garanterade upptiden gäller per tjänst, inte per applikation. Om din applikation beror på compute, databas och lastbalansering — alla med 99,9 % SLA — blir den sammansatta tillgängligheten lägre. Det är ditt ansvar att arkitektera redundans, inte leverantörens.
Prestandamått och mätning
Upptid allena räcker inte. En tjänst kan vara tekniskt "uppe" men så långsam att den i praktiken är oanvändbar. Kräv mätvärden för:
- Svarstid (latens): P50, P95 och P99 — inte bara medelvärde. En genomsnittlig svarstid på 50 ms kan dölja att 1 % av förfrågningarna tar 3 sekunder.
- Genomströmning: Garanterad IOPS för lagring, bandbredd för nätverk.
- Resursutnyttjande: Vad händer om leverantören överallokerar en delad infrastruktur?
- Mätmetod: Vem mäter — du eller leverantören? Var mäts det? Leverantörens egna mätetal gynnar alltid leverantören.
Vi rekommenderar alltid oberoende övervakning. Opsios NOC använder extern syntetisk monitorering som komplement till leverantörens egna dashboards — det är den enda källan som håller i en SLA-tvist. Managerade molntjänster
Vill ni ha expertstöd med sla för molntjänster: så granskar du avtalet rätt?
Våra molnarkitekter hjälper er med sla för molntjänster: så granskar du avtalet rätt — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Hur ett SLA påverkar din datasäkerhet
SLA:er skrevs historiskt för tillgänglighet och prestanda. Säkerhet hamnade i separata policydokument. Det fungerar inte längre — inte med GDPR, NIS2 och den hotbild vi ser 2026.
Dataskyddskrav i avtalet
Ett SLA bör explicit ange:
- Kryptering: At rest (AES-256 minimum) och in transit (TLS 1.3). Vem äger och hanterar nycklarna? Customer-managed keys (CMK) bör vara standard för känslig data.
- Åtkomstkontroll: Leverantörens personalens åtkomst till kunddata — under vilka omständigheter, med vilken loggning?
- Säkerhetskopiering: RPO (Recovery Point Objective) och RTO (Recovery Time Objective) — inte vaga löften om "regelbundna backuper".
- Dataresidenskrav: I vilka regioner lagras data? För svenska organisationer är eu-north-1 (Stockholm) eller Sweden Central ofta ett krav, men det måste stå i avtalet.
GDPR och NIS2 — vad SLA:et måste täcka
GDPR kräver ett databehandlingsavtal (DPA) enligt artikel 28. Men DPA:t och SLA:et lever ofta i separata dokument utan korsreferenser. Det skapar en gråzon när en incident inträffar.
NIS2-direktivet, som trädde i kraft i EU-medlemsstaterna 2024, skärper kraven ytterligare. Organisationer som omfattas av direktivet måste säkerställa att deras molnleverantörer:
- Rapporterar incidenter inom 24 timmar (tidig varning) och ger en fullständig rapport inom 72 timmar
- Har dokumenterade rutiner för supply chain-säkerhet
- Möjliggör tillsyn och revision från kundens sida
Om ditt SLA inte speglar dessa krav riskerar du sanktioner från Integritetsskyddsmyndigheten (IMY) eller MSB — inte leverantören. Molnsäkerhet
Incidentrespons och eskalering
Det mest kritiska testet av ett SLA inträffar vid en säkerhetsincident. Avtalet bör definiera:
- Allvarlighetsgrader: Minst tre nivåer (kritisk, hög, normal) med specifika responstider för var och en.
- Kommunikationskedja: Namngivna kontakter, inte bara ett ärendesystem. Vid en kritisk incident vill du ha en telefon att ringa.
- Forensiska rättigheter: Har du rätt att genomföra eller begära en forensisk utredning? Inom vilken tidsram?
- Kommunikation mot tredje part: Vem informerar myndigheter och drabbade registrerade? GDPR artikel 33 kräver anmälan till IMY inom 72 timmar.
Från Opsios SOC-perspektiv: de incidenter som eskalerar sämst är de där ingen vet vem som äger vilken del av svaret. Ett SLA med vaga formuleringar som "leverantören ska vidta rimliga åtgärder" ger dig ingenting klockan tre på natten. Managerad DevOps
Kompensation och servicekrediter — den obehagliga sanningen
De flesta SLA:er för molntjänster erbjuder servicekrediter som kompensation vid brott mot avtalet. AWS ger exempelvis 10 % kredit vid upptid under 99,9 % och 30 % vid under 99,0 % för EC2. Azure och GCP har liknande modeller.
Problemet: servicekrediter kompenserar bara molnkostnaden, inte din affärsförlust. Om din e-handel ligger nere i fyra timmar och du förlorar 500 000 SEK i intäkter, får du kanske 2 000 SEK i kredit. Det är inte kompensation — det är en symbolisk gest.
Vad du kan förhandla om
Med en managerad tjänsteleverantör eller vid enterprise-avtal finns utrymme att förhandla:
- Utökade krediter: Högre procentsats, baserade på total avtalsvärde snarare än enskild tjänst
- Eskaleringstrappor: Automatisk eskalering till senior management efter definierad tid
- Hävningsrätt: Rätt att säga upp avtalet utan kostnad vid upprepade SLA-brott
- Vitesklausuler: Faktisk ekonomisk kompensation, inte bara krediter — ovanligt med hyperscalers men möjligt via MSP-avtal
Dataportabilitet och exit-strategi
Det mest underskattade avsnittet i varje SLA handlar om vad som händer när samarbetet tar slut. Flexeras State of the Cloud har konsekvent visat att vendor lock-in är en av de främsta orosmomenten bland molnanvändare, och ändå saknar många avtal en exit-plan.
Ditt SLA bör reglera:
- Dataformat: I vilka format kan du exportera dina data? Proprietära format innebär beroende.
- Tidsram för export: Hur lång tid har du på dig att hämta data efter avtalets slut?
- Kostnad för export: Egress-kostnader kan bli betydande — AWS tar betalt per GB ut från regionen. Förhandla om ett tak.
- Radering: Hur och när raderas dina data efter export? Kräv skriftlig bekräftelse och certifierad radering.
En solid exit-strategi kräver även teknisk planering — containerisering, IaC och multicloud-redo arkitektur minskar beroendet av en enskild leverantör. Molnmigrering
SLA-granskning: en praktisk checklista
Innan du signerar — eller vid din nästa avtalsöversyn — bör du systematiskt grå igenom följande:
| Område | Nyckelfråga | Varningssignal |
|---|---|---|
| Upptid | Hur definieras och mäts den? | Inga undantag listade, vag mätmetod |
| Prestanda | Vilka latens- och genomströmningsmål? | Bara medelvärden, inga percentiler |
| Säkerhet | Kryptering, åtkomst, incidentrespons? | Hänvisning till "separat policy" utan länk |
| Efterlevnad | GDPR, NIS2, branschspecifika krav? | Ingen DPA, inga revisionsrättigheter |
| Kompensation | Vad händer vid brott? | Bara servicekrediter, inget vitesbelopp |
| Exit | Dataformat, tidsram, kostnad? | Ingen exit-klausul alls |
| Ändringshantering | Kan leverantören ändra SLA ensidigt? | "Vi förbehåller oss rätten att uppdatera" |
Den sista punkten förtjänar extra uppmärksamhet. Hyperscalers uppdaterar sina SLA:er regelbundet, och ändringarna gäller ofta automatiskt. Säkerställ att du har rätt att säga upp avtalet om villkoren ändras till din nackdel.
Opsios perspektiv: vad vi ser i verkligheten
Som managerad tjänsteleverantör med 24/7 SOC och NOC sitter vi ofta i gränslandet mellan kund och hyperscaler. De vanligaste problemen vi stöter på:
1. Kunder som tror att leverantörens SLA täcker hela stacken. AWS garanterar att EC2-instanser är tillgängliga — inte att din applikation fungerar. Allt från operativsystem uppåt är ditt ansvar om du inte har en MSP.
2. SLA:er som aldrig aktiveras. Många organisationer vet inte ens hur de ska rapportera ett SLA-brott eller kräva kredit. Processen har ofta en tidsfrist på 30 dagar.
3. Avsaknad av sammansatt SLA-analys. Ingen räknar på den totala tillgängligheten för en tjänstekedja med fem beroenden.
Vi hjälper kunder att både förhandla och operativt övervaka sina SLA:er — inte för att det är spännande juridik, utan för att det direkt påverkar driftsäkerhet och affärsrisk. Cloud FinOps
Vanliga frågor
Vad är en rimlig upptidsgaranti i ett SLA för molntjänster?
De stora hyperscalerna (AWS, Azure, GCP) erbjuder typiskt 99,9–99,99 % upptid på enskilda tjänster. Men det gäller per tjänst, inte din applikation som helhet. En sammansatt arkitektur med tre tjänster à 99,9 % ger en teoretisk upptid på 99,7 %. Kräv alltid tydlig definition av hur upptiden mäts och vilka undantag som gäller.
Hur påverkar GDPR och NIS2 mitt SLA med en molnleverantör?
GDPR kräver ett databehandlingsavtal (DPA) som reglerar personuppgiftsbehandling, underbiträden och överföringar till tredjeland. NIS2-direktivet ställer dessutom krav på incidentrapportering inom 24 timmar och supply chain-säkerhet. Ditt SLA bör explicit referera till båda regelverken och ange ansvar vid bristande efterlevnad.
Vad händer om molnleverantören bryter mot sitt SLA?
De flesta SLA:er erbjuder servicekrediter — ofta 10–30 % av månadskostnaden för den drabbade tjänsten. Det täcker sällan den verkliga affärskostnaden av ett avbrott. Förhandla om utökade kompensationsklausuler, eskaleringsrutiner med namngivna kontakter och rätt att häva avtalet vid upprepade brott.
Ska jag ha separata SLA:er för olika molntjänster?
Ja, i praktiken. IaaS, PaaS och SaaS har helt olika prestandaegenskaper och riskprofiler. En databas-SLA bör ha strängare krav på datakonsistens och backup-frekvens än en CDN-tjänst. Samla gärna allt i ett ramavtal men med tjänstespecifika bilagor.
Hur ofta bör jag se över mitt SLA?
Minst årligen, och alltid vid större förändringar — ny leverantör, ny tjänst, nya regulatoriska krav eller efter en allvarlig incident. Hyperscalers uppdaterar sina standardvillkor löpande, och det är ditt ansvar att hålla dig ajour.
Om författaren
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.