SLA för IT-drift: så bygger du avtal som faktiskt håller
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
SLA för IT-drift: så bygger du avtal som faktiskt håller
Ett SLA (Service Level Agreement) för IT-drift är det formella avtalet som definierar exakt vilken servicenivå en leverantör ska leverera — med mätbara mål, tydliga ansvarsförhållanden och specificerade konsekvenser vid avvikelse. Rätt utformat styr det alltifrån incidenthantering till kapacitetsplanering. Fel utformat är det ett dokument som ingen läser förrän något redan gått sönder. Den här artikeln utgår från vad vi på Opsio ser i vår 24/7 SOC/NOC-drift och ger dig verktygen att bygga SLA:er som håller i produktion.
Viktiga slutsatser
- Ett SLA är ett mätbart avtal som definierar exakt vilken servicenivå IT-leverantören ska leverera — inte en avsiktsförklaring
- Dåliga SLA:er saknar prioriteringslogik och eskaleringsvägar, vilket gör dem värdelösa vid incidenter
- KPI:er som tillgänglighet, MTTR och svarstid måste vara kopplade till affärskonsekvens — inte bara tekniska mätvärden
- SLA bör revideras kvartalsvis mot verkliga driftsdata, inte ligga i en låda tills något går sönder
- Branschspecifika krav (NIS2, GDPR, patientdatasäkerhet) gör att generiska SLA-mallar sällan räcker
Vad ett SLA faktiskt är — och inte är
Låt oss börja med att rensa upp en vanlig missuppfattning. Ett SLA är inte en önskelista om att "allting ska fungera". Det är ett juridiskt bindande avtal mellan kund och tjänsteleverantör som specificerar:
- Vilka tjänster som omfattas
- Vilken kvalitetsnivå som ska levereras (mätt i konkreta KPI:er)
- Hur avvikelser hanteras — svarstider, eskalering, kommunikation
- Vad som händer om leverantören inte levererar (servicekrediter, viten, uppsägningsrätt)
Det många kallar "SLA" är i praktiken ett SLO — ett internt mål utan avtalsmässig tyngd. Skillnaden spelar roll. Google formaliserade tredelningen SLA/SLO/SLI i sin SRE-praktik, och den är värd att förstå:
| Begrepp | Vad det är | Exempel |
|---|---|---|
| SLI (Service Level Indicator) | Det faktiska mätvärdet | 99,94% uppmätt tillgänglighet senaste månaden |
| SLO (Service Level Objective) | Det interna målet | Vi siktar på 99,95% tillgänglighet |
| SLA (Service Level Agreement) | Det avtalade löftet med konsekvenser | Leverantören garanterar 99,9% tillgänglighet; vid brott utfärdas servicekrediter |
SLO:t bör alltid vara striktare än SLA:et. Om du lovar kunden 99,9% men siktar internt på 99,95% har du en marginal att arbeta med. Driver du din drift på exakt SLA-nivå lever du på gränsen till avtalsbrott.
Vill ni ha expertstöd med sla för it-drift: så bygger du avtal som faktiskt håller?
Våra molnarkitekter hjälper er med sla för it-drift: så bygger du avtal som faktiskt håller — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
De KPI:er som faktiskt betyder något
Ett SLA utan mätbara KPI:er är ett tomt papper. Men lika problematiskt är ett avtal fullt av tekniska mätvärden som ingen i ledningen förstår eller bryr sig om. Nyckeln är att koppla varje KPI till affärskonsekvens.
Tillgänglighet (Uptime)
Det mest grundläggande måttet, men också det mest missförstådda. Skillnaden mellan 99,9% och 99,99% låter marginell — men i praktiken handlar det om tio gånger så mycket tillåten nertid:
| Tillgänglighetsnivå | Tillåten nertid per år | Tillåten nertid per månad | Typisk användning |
|---|---|---|---|
| 99,0% | ~87,6 timmar | ~7,3 timmar | Interna utvecklingsmiljöer |
| 99,5% | ~43,8 timmar | ~3,6 timmar | Icke-kritiska interna system |
| 99,9% | ~8,7 timmar | ~43,8 minuter | Standardnivå för affärsapplikationer |
| 99,95% | ~4,4 timmar | ~21,9 minuter | Viktiga kundriktade tjänster |
| 99,99% | ~52,6 minuter | ~4,4 minuter | Affärskritiska system, betalningsflöden |
Vår rekommendation: kräv aldrig en generell tillgänglighetsnivå för allt. Klassificera era tjänster i tre till fyra kritikalitetsnivåer och tilldela rätt SLA per nivå. Ett internt intranät och en betalningsplattform har fundamentalt olika krav.
MTTR — Mean Time to Resolve
Tillgänglighet mäter hur ofta saker går sönder. MTTR mäter hur snabbt de lagas. I vår SOC/NOC ser vi att MTTR-målet ofta saknas i SLA:er, trots att det är det mått som användarna faktiskt upplever. En incident som pågår i fyra timmar en lördagsnatt är statistiskt obetydlig för årsuptime — men den kan kosta miljoner i utebliven försäljning.
Svarstid vs. lösningstid
Här sker det vanligaste misstaget i SLA-formulering. Svarstid (hur snabbt leverantören bekräftar incidenten) är inte samma sak som lösningstid (hur snabbt problemet faktiskt är åtgärdat). Många leverantörer lovar snabb svarstid — "vi bekräftar inom 15 minuter" — men specificerar aldrig lösningsmål. Det innebär att de tekniskt sett uppfyller SLA genom att skicka ett autosvar medan incidenten pågår i timmar.
Ställ krav på båda. En rimlig prioriteringsmodell:
| Prioritet | Beskrivning | Svarstid | Lösningsmål |
|---|---|---|---|
| P1 — Kritisk | Affärskritisk tjänst helt nere | 15 minuter | 2 timmar |
| P2 — Hög | Allvarlig funktionspåverkan, workaround finns | 30 minuter | 4 timmar |
| P3 — Medium | Begränsad påverkan, enskilda användare | 2 timmar | 8 timmar (kontorstid) |
| P4 — Låg | Kosmetiskt, ingen affärspåverkan | Nästa arbetsdag | Planerad release |
Eskalering — den bortglömda KPI:n
Om P1-incidenten inte är löst inom lösningsmålet — vad händer då? Ett robust SLA specificerar eskaleringsvägar: vem kontaktas, inom vilken tidsram, och vilka befogenheter har eskaleringsnivåerna. Utan detta fastnar incidenter i first-line support medan verksamheten blöder.
Branschspecifika SLA-krav
Ett generiskt SLA fungerar för generiska behov. De flesta organisationer har inte generiska behov. Managerade molntjänster
Offentlig sektor och myndigheter
Krav på datasuveränitet — data ska lagras inom EU, ofta inom Sverige specifikt. NIS2-direktivet skärper kraven på incidentrapportering (24 timmars initial notifiering, 72 timmars fullständig rapport). SLA:et behöver spegla dessa tidsramar, inte bara leverantörens standardprocess.
Hälso- och sjukvård
Patientdatalagen (PDL) och GDPR ställer extremt höga krav på tillgänglighet och säkerhet. Ett journalsystem som ligger nere äventyrar patientsäkerheten. Här pratar vi 99,99% tillgänglighet med MTTR på under 30 minuter för P1 — och det måste gälla dygnet runt, inte bara kontorstid.
Finans och betalningar
Regulatoriska krav från Finansinspektionen, PSD2 och kommande DORA-krav innebär att SLA:et måste adressera inte bara tillgänglighet utan även revisionsbarhet, loggning och tredjepartsgranskning. Servicekrediter räcker sällan som enda konsekvens — avtalet bör inkludera rätt till oberoende revision.
Tillverkande industri
Här är det ofta systemintegration som är kritisk — ERP, MES, SCADA-system som måste tala med varandra. SLA:et behöver definiera ansvar för integrationspunkter, inte bara enskilda system. Ett system kan ha 99,99% uptime men vara värdelöst om integrationen till produktionslinjen är nere.
Så bygger du ett SLA som fungerar i molnet
Molnmiljöer förändrar SLA-dynamiken på flera sätt. AWS, Azure och Google Cloud har egna SLA:er för sina tjänster — och de är generösa med undantag. Molnmigrering
Shared Responsibility Model och SLA-gapet
Molnleverantörens SLA täcker deras infrastruktur. Det täcker inte er applikation, er konfiguration eller er data. Om en RDS-instans i eu-north-1 (Stockholm) har en tillgänglighet på 99,95% enligt AWS SLA, men er applikation kraschar på grund av en felkonfigurerad security group — är det inte AWS problem.
En managerad tjänsteleverantör som Opsio fyller gapet mellan molnleverantörens ansvar och det ni faktiskt behöver. Vårt SLA täcker det som AWS/Azure inte gör: övervakning, incidenthantering, konfiguration, patchning och eskalering.
Multi-cloud och SLA-komplexitet
Enligt Flexeras State of the Cloud har multi-cloud blivit normen snarare än undantaget bland företag. Det skapar en SLA-utmaning: vem äger incidenten när problemet spänner över AWS och Azure? Ert SLA med en MSP behöver en tydlig klausul om ansvar för cross-cloud-incidenter. Cloud FinOps
Infrastruktur som kod och SLA-verifiering
Med IaC-verktyg som Terraform och Pulumi kan SLA-efterlevnad delvis automatiseras. Tillgänglighetsövervakning, automatisk failover och self-healing kan skrivas in i infrastrukturdefinitionen. Men SLA:et behöver specificera vem som ansvarar för IaC-koden — är det er interna DevOps-organisation eller leverantören? Managerad DevOps
Fem fallgropar vi ser i kundavtal
Från vår erfarenhet med hundratals SLA-granskningar pekar vi ut de vanligaste misstagen:
1. Procentmått utan mätperiod. "99,9% tillgänglighet" — per månad eller per år? Skillnaden är enorm. Kräv månadsvis mätning med månatlig rapportering.
2. Undantag som äter upp avtalet. "Planerat underhåll undantas." Okej — men hur mycket planerat underhåll tillåts? Utan tak kan leverantören schemalägga nertid varje vecka och fortfarande uppfylla SLA.
3. Mätning utan oberoende källa. Om leverantören själv mäter sin tillgänglighet har ni ett trovärdighetsproblem. Kräv tredjepartsövervakning eller åtminstone delad åtkomst till övervakningsverktyget.
4. Avsaknad av servicekatalog. SLA:et refererar till "IT-tjänsten" utan att definiera vad som ingår. Är e-post inkluderat? VPN? Backup-restore? En fullständig servicekatalog är grunden.
5. Statiskt avtal utan revisionsklausul. IT-miljöer förändras snabbt. Ett SLA som skrevs 2024 för en on-prem-miljö är sannolikt irrelevant 2026 när halva infrastrukturen är i molnet. Bygg in kvartalsvis genomgång.
Säkerhet och SLA — NIS2-perspektivet
NIS2-direktivet, som trädde i kraft i EU under 2024, ställer nya krav som direkt påverkar SLA-utformningen. Väsentliga och viktiga entiteter måste säkerställa att deras leverantörsavtal adresserar: Molnsäkerhet
- Incidentrapporteringstider — 24 timmar för initial notifiering, vilket innebär att SLA:ets eskaleringsprocess måste vara snabbare
- Supply chain security — ni är ansvariga för era leverantörers säkerhet, och SLA:et behöver ge er insyn
- Kontinuitetsplanering — SLA:et måste täcka disaster recovery med specifika RTO/RPO-mål
- Revision och tillsyn — Integritetsskyddsmyndigheten (IMY) och andra tillsynsmyndigheter kan kräva insyn i leverantörsavtal
Praktisk checklista: innan du signerar
Använd den här listan innan nästa SLA-förhandling:
- [ ] Är alla tjänster tydligt definierade i en servicekatalog?
- [ ] Finns KPI:er för tillgänglighet, svarstid OCH lösningstid?
- [ ] Är mätperiod specificerad (månadsvis rekommenderas)?
- [ ] Finns en prioriteringsmatris (P1–P4) med tydliga definitioner?
- [ ] Är eskaleringsvägar dokumenterade med namngivna kontakter?
- [ ] Finns tak för planerat underhåll?
- [ ] Finns konsekvenser vid SLA-brott (servicekrediter, viten, uppsägning)?
- [ ] Täcker avtalet NIS2-krav om incidentrapportering?
- [ ] Finns RTO- och RPO-mål för disaster recovery?
- [ ] Är revisionsklausul inkluderad (kvartalsvis genomgång)?
- [ ] Är mätning oberoende eller delad?
- [ ] Hanterar avtalet multi-cloud/hybrid-scenarier?
Vanliga frågor
Vad är skillnaden mellan SLA, SLO och SLI?
SLA är det formella avtalet med kunden om servicenivå och konsekvenser vid avvikelse. SLO (Service Level Objective) är det interna målet — ofta striktare än SLA. SLI (Service Level Indicator) är det faktiska mätvärdet, exempelvis uppmätt tillgänglighet. Google populariserade denna tredelning inom SRE-praktiken, och den är standarden i moderna driftorganisationer.
Hur ofta bör ett SLA revideras?
Kvartalsvis som minimum, med en formell genomlysning årligen. SLA som skrevs för on-prem-miljöer gäller sällan rakt av i molnet. Vid större förändringar — molnmigrering, ny leverantör, regulatoriska uppdateringar som NIS2 — bör SLA:et omförhandlas direkt.
Vilken tillgänglighetsnivå ska vi kräva — 99,9% eller 99,99%?
Det beror på affärskonsekvensen av nertid. 99,9% tillåter cirka 8,7 timmars nertid per år — tillräckligt för många interna system. 99,99% (under 53 minuter per år) krävs för affärskritiska system men kostar markant mer i redundans. Välj nivå per tjänst, inte som en generell siffra.
Vad händer om leverantören inte lever upp till SLA?
Avtalet ska specificera konsekvenser: servicekrediter, prisreduktion eller i allvarliga fall uppsägningsrätt. Men det viktigaste är inte straffet — det är eskaleringsprocessen. Ett SLA utan tydlig eskalering är tandlöst oavsett vilka viten som skrivs in.
Behöver vi separata SLA för molntjänster och on-prem?
Ja. Molnleverantörer som AWS, Azure och Google Cloud har egna SLA:er för sina tjänster. Ert SLA med en MSP behöver hantera gapet mellan molnleverantörens ansvar och det ni faktiskt behöver. Det är i det gapet som incidenter faller mellan stolarna.
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.