SLA SaaS-sopimuksissa – käytettävyys, vasteaika, RTO, RPO ja palveluhyvitykset

Mallbutiken · Tiedot tarkistettu 30. syyskuuta 2026 · Noin 8 minuutin lukuaika

SLA tekee SaaS-palveluntarjoajan palvelutasosta mitattavan. Sen tulisi määritellä, mitä käytettävyydellä tarkoitetaan, miten se lasketaan, miten häiriöt priorisoidaan, mitkä vasteajat ovat voimassa, mitkä palautumistavoitteet ovat relevantteja ja mitä asiakas saa, jos palvelutaso ei täyty.

Mikä on SLA SaaS-sopimuksessa?

SLA eli Service Level Agreement on usein pääsopimuksen liite. Pääsopimuksessa kuvataan kaupallinen suhde, kun taas SLA täsmentää jatkuvan palvelun mitattavat laatutasot.

Hyvän SLA:n tulisi toimia sekä normaalissa käytössä että silloin, kun jokin menee vikaan. Jos osapuolet alkavat vasta häiriön ilmetessä keskustella siitä, mitä ”kriittinen häiriö” tai ”99,9 prosentin käytettävyys” tarkoittavat, sopimus on liian epäselvä.

Katso myös pääopas siitä, mitä SaaS-sopimuksen tulisi sisältää.

Käytettävyys – prosenttiluku on vasta alkua

Käytettävyystaso, esimerkiksi 99,9 prosenttia, ei kerro paljoakaan ilman mittaussääntöjä. Määritä siksi:

• mitä palvelua tai komponentteja se koskee,
• mittausjakso, esimerkiksi kalenterikuukausi,
• mikä tietolähde on käytössä,
• milloin käyttökatko alkaa ja päättyy,
• vähennetäänkö suunniteltu ylläpito,
• miten asiakkaan aiheuttamat virheet tai ylivoimainen este (force majeure) käsitellään,
• voidaanko suorituskyvyn heikkeneminen laskea käyttökatkoksi.

Ero 99,9 ja 99,99 prosentin välillä voi olla kaupallisesti suuri. Vaatimuksen tulisi siksi perustua siihen, kuinka liiketoimintakriittinen palvelu on ja mitä palveluntarjoajan tekninen arkkitehtuuri todellisuudessa pystyy tarjoamaan.

Häiriöluokat ja vasteaika

Häiriöluokittelun tulisi perustua vaikutuksiin, ei vain tekniseen virhetyyppiin. Virhe voi olla teknisesti rajoittunut, mutta liiketoimintakriittinen, jos se esimerkiksi estää maksut tai pääsyn keskeiseen prosessiin.

Kullekin prioriteettitasolle SLA voi määritellä ensimmäisen vasteajan, tavoiteajan kiertotielle tai palauttamiselle, päivitystiheyden ja eskalointitason. Ole tarkkana vasteajan ja ratkaisuajan erosta. Vastaus 30 minuutissa ei automaattisesti tarkoita, että virheen on oltava korjattu 30 minuutissa.

Tukipalvelun aukioloaikojen on vastattava liiketoimintaa

P1-vasteaika 30 minuuttia on hyödytön ympäri vuorokauden toimivalle yritykselle, jos palveluntarjoajan tuki on auki vain arkisin klo 09–17. Määritä, mitkä tasot ovat voimassa varsinaisten aukioloaikojen ulkopuolella ja miten kriittisistä häiriöistä raportoidaan.

RTO ja RPO – kaksi eri palautumistavoitetta

RTO (Recovery Time Objective) on tavoite sille, kuinka nopeasti palvelu tai prosessi on voitava palauttaa katkoksen jälkeen. RPO (Recovery Point Objective) on tavoite sille, kuinka suuri ajallinen datahäviö palautustilanteessa voidaan sietää.

Näitä ei tulisi valita IT-sopimuksessa erillään muusta. BIA (Business Impact Analysis) voi osoittaa, kuinka kauan liiketoiminta todellisuudessa kestää katkosta ja mikä datahäviö on hyväksyttävää. Lue opas Business Impact Analysis -analyysistä ja käytännön BIA-esimerkki.

Tarkista myös, mitä palveluntarjoaja tarkoittaa arvoillaan. Onko RTO tavoite, takuu vai vain sisäinen suunnitteluperiaate? Koskeeko RPO kaikkia datatyyppejä? Kuinka usein palautusta testataan?

Palveluhyvitykset – kompensaatio vai ainoa seuraamus?

Palveluhyvitykset voivat luoda automaattisen taloudellisen kannustimen, jos palvelutasoa ei saavuteta. Portaikko voi esimerkiksi tarjota suuremman hyvityksen, mitä enemmän palvelu alittaa tavoitetason.

Tarkista kuitenkin, sanotaanko sopimuksessa, että palveluhyvitys on asiakkaan ainoa seuraamus. Vakavien tai toistuvien puutteiden kohdalla asiakas saattaa tarvita muita oikeuksia, kuten oikeuden toimintasuunnitelmaan, erityiseen eskalointiin tai sopimuksen irtisanomiseen. Yhteensovita SLA pääsopimuksen vastuunrajoitusten ja irtisanomissääntöjen kanssa.

Suunniteltu ylläpito ja muut poikkeukset

Palveluntarjoajan on yleensä voitava huoltaa palvelua, mutta liian laaja poikkeus voi tehdä käytettävyystavoitteesta harhaanjohtavan. Säädä, kuinka ajoissa ylläpidosta on ilmoitettava, mitä aikaikkunoita saa käyttää ja käsitelläänkö kiireellistä tietoturvaylläpitoa eri tavalla.

Ole myös varovainen kolmannen osapuolen palveluita koskevien poikkeusten kanssa. Jos palveluntarjoaja on itse valinnut kriittisen pilvi- tai infrastruktuuritoimittajan, sopimuksen tulisi selventää, miten riippuvuus vaikuttaa SLA-tasoon ja vastuuseen.

Muistilista käyttökelpoiseen SLA-sopimukseen

• Onko mitattava palvelu määritelty selkeästi?
• Onko olemassa yksiselitteinen kaava käytettävyydelle?
• Onko suunniteltu ylläpito rajattu?
• Onko häiriöluokat kytketty liiketoimintavaikutuksiin?
• Erotteleeko sopimus vasteen, kiertotien ja ratkaisun?
• Toimiiko tuki kriittisinä käyttöaikoina?
• Onko RTO/RPO kytketty todellisiin jatkuvuuden tarpeisiin?
• Onko tilannepäivityksistä vaatimus P1-häiriöiden aikana?
• Ovatko palveluhyvitykset ja muut seuraamukset selkeitä?
• Onko oikeutta toimia toistuvien SLA-rikkomusten yhteydessä?

Tarvitsetteko pääsopimuksen ja SLA:n samassa rakenteessa?

Mallbutikenin SaaS-sopimus sisältää pääsopimuksen ja kuusi liitettä, kuten palveluspesifikaation, SLA:n, PUB/GDPR:n, tietoturvan, exit-suunnitelman ja hinnan. Word ja PDF. Hinta kaupassa: 149 kr.

Katso SaaS-sopimus

Usein kysyttyjä kysymyksiä

Onko 99,9 prosenttia aina hyvä SLA?

Ei. Oikea taso riippuu palvelun kriittisyydestä, mittausmenetelmästä, poikkeuksista ja korkeamman redundanssin kustannuksista. Prosenttiluku on asetettava oikeaan yhteyteensä.

Onko RTO sama asia kuin SLA-käytettävyys?

Ei. Käytettävyys mittaa yleensä toimivuutta tietyn ajanjakson yli. RTO käsittelee tavoitetta palautumiselle katkoksen jälkeen.

Pitäisikö palveluhyvityksen olla ainoa seuraamus?

Tämä on sopimuskysymys, mutta asiakkaan tulisi harkita tietoisesti, riittääkö pelkkä hyvitys vakavien tai toistuvien puutteiden yhteydessä.