Nedanstående tabell är ett exempel på checklista för grundutvärdering av ett avtalsförslag runt SAAS-tjänst. Till dessa läggs punkter runt kostnadsmodell (ofta kostnad per användare och månad, men kan finnas andra konstruktioner), klargörande runt eventuella vanliga integrationer som MS-Active Directory, möjlighet till integration med SingleSign-On-lösning etc.

Normalt hänvisar ett driftavtal till allmänna villkor, som ett ”skyddsnät” för hantering av de punkter som inte uttryckligen är beskrivet i driftavtalet. I Sverige är det vanligt att leverantör använder IT&Telekomföretagen Almega ”Allmänna bestämmelser Molntjänster version 2014”. Om leverantör hänvisar till andra allmänna villkor rekommenderas att jämföra dessa mot villkoren i IT&Telekomföretagens.

NrChecklista IT-tjänst levererad som SAASSvar?Lathund för utvärdering
1Finns ansvarsförsäkringar för tjänste- och driftsleverantör? Alla har ansvarsförsäkring. Om inget svar eller nej = RED FLAG
2Avtalstid?Längre avtal större vikt vid alla andra parametrar.
3Vilka regler gäller runt avtalsavslut?Vanligtvis avslutas ett avtal med uppsägning från någon part då avtalstiden börjar närma sig sitt slut. Onormala avslut sker om någon av parterna begår avtalsbrott, går i konkurs, eller via någon klausul i avtalet (t ex efter uppköp eller prisförändring). Normalt sätt, från en seriös leverantör, finns dessa olika undantag beskrivna.
4Hur avslutas tjänsten normalt? Hur hanteras kunddata vid avslutning? Hur uppsägning, eller meddelande om uppsägning, görs skall vara beskrivet. Det är viktigt att hantering av kunddata är beskrivet i samband med avslut. Vem (kund eller leverantör) ansvarar för att kunden får tillbaka data, i vilket format får man tillbaka data etc. Om detta inte finns beskrivet = RED FLAG
5Vad sker med tjänsten och kunddata i händelse av konkurs (av leverantören eller underleverantör)?Ett sätt att lösa detta är att koncernbolag ansvarar/övertar avtalet i händelse av konkurs. Annat sätt är att det blir ett avslut av avtalet. Frågan är hur kunddata hanteras, och ett ev avtalsåtagande att skicka tillbaka kunddata vid avtalsslut.
6Vilka olika speciella skäl och scenarios finns till avslut? Finns det skillnader bland dessa hur avsluten praktiskt hanteras?Stora SAAS-leverantörer har ofta en serie olika typer av möjliga speciella avslut, ibland för att gardera sig mot kunder som hanterar tjänsten på ett sätt som inte är tänkt. Från kundens sida är det speciellt viktigt då tjänsten är affärskritisk att avsluten, även speciella avslut, har en framförhållning. Worst case: Leverantören kan säga upp avtalet och stänga av tjänsten vid t ex enkel betalningspåminnelse.
7Dataformat och möjlighet till integration med andra tjänster?Givetvis bra med öppna enkelt hanterbara dataformat som kan kopplas till andra tjänster ( tex XML-strukturer). Om dataformatet är leverantörsspecifikt och inte öppet = RED FLAG
8Beskrivning av övergripande driftsmiljön av tjänsten (dedicerad server, delad server, virtualisering, redundans, lösning för datalagring etc)En beskrivning som skall motsvara vad som förväntas. Ger också förklaring till prisbild och hur leverantörens direkta kostnader ser ut.
9Geografisk placering av driftshallar?Utanför EU = RED FLAG. Flera amerikanska leverantörer erbjuder placering i USA under "Safe Harbor", dvs följer EU's regelverk för datahantering vilket kan vara OK. Placering inom EU OK, Norden är bra.
10Eventuella underleverantörer/driftspartners av betydelse för tjänsten (namn, orgnr)? Det är viktigt att förstå förhållandet mellan avtalsparten och driftsleverantören, om det inte är samma företag. Det finns flera olika typer av upplägg där t ex en avtalspart enbart hanterar avtalet, avtalspart hyr drift av fysisk utrustning från driftsbolaget och sedan säljer kapaciteten som delad server till kund etc. Viktiga parametrar är: Vem skriver vi avtal med? Vem förser oss med driftstatistik och uppföljning av garantier? Vem hanterar felanmälan? Vem garanterar och hanterar kunddata? Vem hanterar avtalsavslut? Namn och orgnr viktigt för att göra en leverantörsbedömning även av central underleverantör. Inga klara svar eller ingen transparens = RED FLAG.
11Övriga lösningar för att säkra redundans och kapacitet i driftenJu mer redundans desto bättre. Finns ej eller utelämnat svar = RED FLAG
12Antalet kunder till driftsleverantören?Bedömningssak. Ju fler desto bättre i vissa avseenden (har volym/ekonomi för att nyttja storsdriftsfördelar och på sätt högre driftssäkerhet, sämre i andra (val av servicefönster, förändringshantering).
13Finns kundreferens till driftsleverantören?Givetvis värdefullt vid utvärdering av leverantör. Finns ingen kundreferens = RED FLAG
14Driftsleverantörens tekniska kapacitet? (antal anställda driftstekniker, serverhallar, etc)Ju fler tekniker och serverhallar desto bättre ur stordriftssynvinkel.
15Driftsleverantörens tekniska kompetens? (certifieringar etc)Det finns inte samma marknadstryck på certifieringar inom IT-drift som inom IT-konsultsidan. Är en värdemätare, i något avseende, på kompetensnivå.
16Ev samarbetspartners för att stärka teknisk kapacitet eller kompetens?Vanligt att ett mindre driftsföretag visar på partnerskap för att stärka kompetens och kapacitet. Ett litet företag utan parters kan vara RED FLAG
17Vad gäller runt förändringar i tjänstens funktion?Införande av förändringar från leverantörens sida måste rimligtvis godkännas av kund. Finns det många kunder på en SAAS-tjänst är detta en utmaning. Normalt är information till kund och en framförhållning på t ex 1 månad, för införande av förändring, som kan påverka tjänsten i något avseende negativt.
18På vilket sätt och inom vilka tidsfönster kan felanmälan göras?Skall matcha behovet av tjänsten. Via telefon normalt under kontorstid, mail/web dygnet runt.
19Vilken garanterad åtgärdsstart och åtgärdstid finns?Normalt finns garanterad åtgärdsstart efter en kund- eller leverantörsstyrd prioritering av felet. Garanterad åtgärdstid (fixtid) är ovanligt. Finns ingen åtgärdsstart angiven = RED FLAG
20Hur görs återrapportering efter åtgärd?Normalt skall löst fel rapporteras till den som felanmält, via t ex mail, telefon, SMS. Om inte detta hanteras är det = RED FLAG
21Eskaleringsrutiner?Normalt finns tekniska- och organisatoriska eskaleringsrutiner. Tekniska: vid svårare fel hitta ngn mer avancerad tekniker eller i vissa fall producent som löser problemet. Organisatoriska: informera i leverantörs- och kundorganisationen vid svårare fel, eller fel som tar lång tid att lösa. Finns inga eskaleringsrutiner är det inte bra.
22Redundans och kapacitet mot Internet?Kapacitet mot internet från leverantören är viktigt (speciellt mindre leverantörer). Redundans i routers och anslutningar, anslutningstyper etc. För större globala SAAS-leverantörer är detta en självklarhet.
23Redundans av internetoperatörer (Finns t ex egen BGP-routing)?En seriös leverantör har minst 2 olika internetoperatörer och administrerar en BGP-routing, eller motsvarande. Inget svar eller ingen redundans = RED FLAG. För större globala SAAS-leverantörer är detta en självklarhet.
24Typ av klientanslutning (t ex TLS/SSL)? Typ av ev certifikat (Certificate Authority)?Säkrad klientanslutning är idag i princip alltid baserat på TLS/SSL med kryptering och certifikatshantering. Typen av certifikat, certifikatsutfärdaren (CA), ger en fingervisning om kvalité och säkerhetstänk hos driftsleverantören. Det finns certifikat på domänivå (enklare nivå), organisationsnivå (vanligast) samt extended (enbart större banker och stora aktörer). Som tillägg kan läggas någon form av lösning för engångslösenord. Finns lösenordskyddad affärskritisk funktion/tjänst som inte är skyddad av TLS/SSL eller kraftfullare lösning = RED FLAG.
25Ev krav på Internet browser/läsare?Krav på speciell typ av browser, t ex enbart MS Internet Explorer = RED FLAG. Versionskrav, kopplade till de marknadsledande, är OK.
26Ev bandbreddskrav per användare för acceptabla svarstider?Oftast aktuellt i TS/Citrix-lösningar. I normala web-applikation brukar detta inte vara ett problem.
27Prismodell och hur regleras förändringar av priser:Prismodellen kan se ut på olika sätt men det som är viktigt är hur man reglerar en förändring av priser. Normalt finns en indexuppräkning årligen eller en klausul som ger leverantören rätt att höja priser mot att kunden får rätt att avsluta avtalet i förtid. En ensidig rätt för leverantören att höja priset i ett avtal över 12 månader eller mer, utan en förtida uppsägningsrätt av kunden = RED FLAG.
28Beskriv regler och policy runt ev servicefönster som påverkar tjänsten? (Planering och kundinformation)Normalt räknas inte servicefönster in i tillgänglighetskalkyler. Det finns normalt en plan med regelbundet servicefönster och en angiven tid för framförhållning då leverantören meddelar om servicefönstret skall användas. Framförhållningen kan variera från en vecka till en månad. Servicefönster ligger normalt utanför kontorstid och ca en gång per månad. Stora globala aktörer har inte servicefönster. Ett servicefönster per vecka, under, eller i anslutning till kontorstid = RED FLAG.
29Hur bedrivs det övergripande säkerhetsarbetet som påverkar eller kan påverka driften av den aktuella tjänsten?Seriösa aktörer har svar på denna fråga, oftast genom en hänvisning till en IT-säkerhetsstandard som samlingsbegreppet: SS-ISO/IEC 27000 eller specifikt ISO/IEC 17799. Inget svar (eller ”nonsens”-svar) = RED FLAG
30Hur ofta genomförs extern revision av IT-säkerheten? I standarden ingår externa revisioner. Följer man ingen vedertagen standard är extern revision en bra fingervisning om säkerhetsarbetet. Inget svar = RED FLAG
31Säkerhetskopiering? Hur länge lagras säkerhetskopior och var?Finns flera olika varianter med disk- och bandlagring. Lagring sker normalt på två olika geografiska ställen. Ingen, eller kort lagringstid, på ett ställe = RED FLAG.
32Katastrofhantering (Finns flera driftshallar? etc)En seriös leverantör har en kontinuitetsplan och någon form av katastrofhantering.
33Hur hanteras kundens data? Applikation- och dataåtkomst? Möjlighet till kundstyrd kryptering? Hantering av ev personuppgifter?Flera olika möjliga svar. Kundstyrd kryptering hindrar leverantörens (och andras) möjlighet till dataåtkomst vilket givetvis höjer säkerheten. I vissa fall avtalar leverantören att denne måste ha tillgång till data för att säkerställa/kontrollera att kunden följer avtalet. Hur skyddet av kunddata ser ut varierar. Personuppgifter: Om det ingår i tjänsten bör leverantören svara på hur persondatahanteringen sker. Ju mer driftsleverantören är involverad i hantering och bestämmer rutinerna i hantering av kunddata, ju mer delar denne rollen som personuppgiftsansvarig (med kunden). Inget svar, eller svaret "PUL" = RED FLAG
34Garanterad tillgänglighet för tjänsten (%):Finns ingen tillgänglighet angiven = RED FLAG . Anges tillgänglighet, som alla seriösa driftsleverantörer gör, påverkar mätmetoder, beräkningsmodeller och tidsfönster. Det är inte självklart att 99,9% är bättre än 99%.
35Beskriv mät- och beräkningsmodell för tillgänglighet:Finns tillgänglighet men inte mät- och beräkningsmodell = RED FLAG. Finns mätmetod och beräkningsmodell är detta normalt tillräckligt. Tidsfönstret, dvs under hur lång tid underlaget till tillgänglighetstalet samlas in är en viktig parameter. Ju kortare tidsfönster desto större krav på driftssäkerhet. Normalt ligger tidsfönster på 1-3 månader. Tidsfönster på 12 månader är mycket fördelaktigt för en driftsleverantör.
36Hur och med vilket intervall presenteras uppnådd tillgänglighet?Normalt presenteras tillgänglighet på månadsbasis, löpande på web bättre, men kvartalsvis kan vara ok. Sättet kan vara pappersrapport, web-rapport eller utskick via e-post. Ingen rapportering av tillgänglighetsuppföljning = RED FLAG
37Finns generell driftstatistik tillgänglig? På vilket sätt?Generell driftstatistik ger en indikation hur stabil tjänsten är. Vanligt att större SAAS-tjänster har generell statistik men inte individuell tillgänglighetsuppföljning.
38Vad är konsekvensen om den garanterade tillgängligheten inte uppnås (teknisk utredning, avgiftsreduktion, skadestånd)?Om man garanterar ett mål för tillgänglighet men inte en avgiftsreduktion kopplad till missat mål känns det inte seriöst. Skadestånd är mycket ovanligt (skadestånd = ersättning för förlorad ekonomisk intjäning eller indirekt kostnad pga driftshaveri). Om leverantören inte är beredd till avgiftsreduktion i något läge känns det oseriöst.