Direktoratet for forvaltning og økonomistyring (DFØ) lanserte forrige uke ny standardavtale, kalt SSA-Sky. DFØ sier selv at avtalen omfatter tjenester knyttet til etablering og forvaltning av komplekse skytjenester. Skytjenestene kan kjøpes gjennom integratoren som del av avtalen, eller være anskaffet direkte av Kunden selv.
Avtalen kommer i tillegg til SSA-L, som har vært ute siden 2018. SSA-L har vært en relativt kort og grei skytjenesteavtale, som har passet for anskaffelse av skytjenester hvor det ikke har vært behov for noe omfattende etableringsprosjekt. «Minuset» med avtalen har vært at den strengt tatt kun har passet for privat sky, da SSA-L stilte krav om at dersom viktig funksjonalitet for kunden endret seg i avtaleperioden så ville dette kunne gi grunnlag for prisavslag, erstatning og heving. I tillegg var integrator ansvarlig for feil i standard skytjenester i godkjenningsperioden.
Nye SSA-Sky har tatt flere skritt videre og er blitt en veldig fin «alt i ett» avtale, hvor integrator tar ansvar for etablering/implementering av ulike tredjeparts skytjenester for kunden, og hvor abonnementet til skytjenestene enten kjøpes gjennom integrator eller av kunden direkte fra skyleverandør. Avtalen er ment å dekke sammensatte leveransemodeller av ulik kompleksitet. Sammenlignet med SSA-L har avtalen en mye mer detaljert regulering av etableringen/implementeringen og tilhørende godkjenning. Det tas høyde for at integrator i etableringsfasen kan lage tilpasninger, integrasjoner, konvertere data, mulighet for å etablere særskilte sikkerhetsløsninger, foreta opplæring, være strategisk rådgiver i omstillingsprosesser mv. Det legges også til rette for at skytjenestene etableres og forvaltes helt eller delvis i parallell, og skytjenester kan etableres og settes i forvaltning i hele avtaleperioden. Særlig kapittel 2 i avtalen, som fokuserer på tilrettelegging og innføring, løpende forvaltning etter etableringen er gjennomført, og en god avslutning, virker veldig bra for de mer komplekse anskaffelsene.
Stor og kompleks avtale
Sammenlignet med SSA-L så skal en imidlertid være obs på at dette er en avtale på hele 46 sider i generell avtaletekst, med tilhørende 33 sider bilag (før bilagene er fylt ut). SSA-Sky er således en stor og kompleks skyavtale som da passer for store og komplekse skyanskaffelser, for eksempel hvor en ønsker å anskaffe og implementere en SaaS løsning, foreta en skyreise som omfatter å flytte hele eller deler av driften av kundens systemer ut i skyen og gjerne også etablere DevOps o.l. Men den blir for stor og kompleks dersom en kjøper enkle skytjenester som krever lite implementering, eller kun abonnement til en standard skytjeneste.
SSA-Sky legger opp til at Kunden må akseptere (som i SSA-L) skyleverandørens vilkår fullt og helt. Noe annet, for eksempel slik som dataforeningens skytjenesteavtale har lagt opp til siste årene, innebærer kun risiko for forbehold fra tilbydere (som har lest og forstått spillereglene for hvordan de kan videreselge), med tilhørende avvisningsplikt om en som kunde er underlagt anskaffelsesregelverket.
Merk for øvrig at avtalen legger opp til at kunden kan kjøpe standard skytjenester enten 1) direkte fra skyleverandør, 2) direkte fra skyleverandør etter anbefaling fra integrator, eller 3) gjennom integrator. Avtalen legger strengt tatt ikke opp til at standardiserte skytjenester tilbys på betingelsene i SSA-sky generelt, kun at egne vilkår for dette legges ved i bilag 10.
Mye er nytt fra SSA-L
SSA-Sky legger også opp til at integrator ikke er ansvarlig for feil i standard skytjenester som integrator har anbefalt eller formidlet. Dette i motsetning til SSA-L og for eksempel Dataforeningens skytjenesteavtale de siste årene. Dette er nok en klok ansvarsregulering, da integratorer som videreselger tredjeparts skytjenester ikke har kontroll nok på tredjeparts skytjenester til å kunne ta ansvar for feil i slike. Samtidig så bør en som kunde være bevisst ansvarsfordelingen og vurdere tiltak dersom det er risiko for at en vil kunne få tilbud basert på kvalitetsmessig dårlige tredjeparts skytjenester. Dette kan imidlertid for eksempel gjøres gjennom kvalifikasjonsrunden eller på andre hensiktsmessige måter, slik at en kan velge vekk løsninger som er for dårlig eller som innebærer for stor risiko.
Så over til noen viktige observasjoner/potensielle fallgruver:
- SSA-Sky legger som SSA-L opp til at dersom skytjenesten endres på en slik måte at krav i bilag 1 ikke lengre oppfylles i perioden frem til Leveringsdag og dette samtidig kvalifiserer til en såkalt «alvorlig feil», så plikter integrator enten 1) å informere Kunden om dette og lage forslag til alternativ måte å levere fjernet funksjonalitet på, eller 2) gi kunden forholdsmessig prisavslag. Det telles imidlertid ikke som en alvorlig feil som vil gi grunnlag for underkjennelse av godkjenningsprøven/utløser forsinkelsesansvar. MEN – integratoren må på egen regning lage workarounds.
Fra et integratorperspektiv innebærer dette en ukontrollerbar risiko i en del prosjekter, og siden integrator normalt ikke har kontroll på hvilke endringer skyleverandør gjør til enhver tid (samme hvor mye en leser roadmaps o.l), så betyr det at integrator enten må prise inn et unødvendig (stort) risikopåslag eller i verste fall må ta forbehold til hele mekanismen. Som offentlig kunde underlagt anskaffelsesregelverket bør en i den enkelte anskaffelse vurdere nøye hvorvidt en er tjent med en slik risikofordeling, da det enten kan medføre et prispåslag en ikke ønsker å betale for, eller i verste fall at en mister tilbydere eller må avvise de (= dårligere konkurranse).
Kan ikke fryse versjoner
Om SSA-Sky for eksempel brukes for implementering av en ERP-løsning, og prosjektet vil ta 2-3 år før løsningen går i produksjon, så betyr dette at en i realiteten ber integrator ta risikoen for at SaaS-leverandøren ikke endrer funksjonalitet i hele 2-3 års perioden på en slik måte at krav i bilag 1 ikke lengre oppfylles av standard funksjonalitet. Det er imidlertid stor risiko for at dette vil skje, da ERP-løsninger levert som SaaS blir oppdatert løpende. Microsoft kommer til eksempel med i alle fall tre større oppdateringer hvert år, og du kan ikke velge å utsette den enkelte i mer enn tre måneder. Det vil si at en kan ikke velge å fryse versjonen en bruker slik som i on-premise verden.
Som kunde bør en vurdere nøye om en virkelig ønsker ansvarsfordelingen på slik måte på grunn av ovennevnte konsekvenser. Realiteten med kravet er at tilbyderne strengt tatt kun bør tilby «privat sky», det vil si det må være mulig å fryse en versjon av løsningen i avtaleperioden. Dette ønsker en ofte ikke som kunde da en nettopp ønsker fordelene av å benytte standardiserte skytjenester som oppdateres jevnlig fremfor å anskaffe klassiske on-premise løsninger som kun er driftet i sky. Vår påstand er at DFØ her har laget en ny skyavtalemal som kun passer for «private cloud» og ikke «public cloud». Workaroundplikten bør således vurderes endret.
- Vær også obs på at avtalen ikke er konsekvent nok i språkbruken. Til eksempel skilles det i avtalens pkt 1.1.2 mellom «Leverandøren er part i avtalen med Skytjenesteleverandøren» vs «Kunden selv er part i avtalen med Skytjenesteleverandøren». Litt avhengig av om tredjeparts skytjeneste er anskaffet på ene eller annen måte, så varierer det om integrator har ansvar for å følge opp skytjenesteleverandøren på Kundens vegne eller ei. Problemet er først og fremst ordlyden «Leverandøren er part i avtalen med Skytjenesteleverandøren». Hva betyr egentlig dette? Mange internasjonale skytjenesteleverandører har to modeller for videresalg. I den ene varianten inngås det en avtale mellom sluttkunde og skytjenesteleverandør i bakkant (og avtalen kan håndheves direkte mellom disse) selv om betaling for skytjenesten går gjennom integrator, og i den andre varianten inngås det ikke avtale mellom sluttkunde og skytjenesteleverandør i bakkant (men integrator har sikret seg rett i sin avtale med skyleverandør til å videreselge til sluttkunden. Bruker en AWS som eksempel så skilles det mellom «End Customer Account Model» vs «Solution Provider Account Model». Det en altså ser er at SSA-Sky ikke bruker terminologi som samsvarer med baklandskapet (det vil si skytjenesteleverandørenes videresalgsmodeller). Og da blir det upresist, og fra et kundeståsted er konsekvensen av 1.1.2 at en tror at integrator vil følge opp skytjenesteleverandøren på kundens vegne der en kjøper skytjenesten gjennom integrator, men i realiteten så får integrator ikke det ansvaret likevel fordi sluttkunden i de fleste tilfeller må akseptere skyleverandørens vilkår på en slik måte at det inngås en direkte avtale mellom skyleverandør og kunde i bakkant. Konklusjonen er at ordlyden bør vurderes endret i pkt. 1.1.2 slik at det i større grad skilles mellom når skytjenesten kjøpes gjennom integrator og direkte av kunde (hvor en som kunde også betaler skyleverandør direkte).
- I oppfølgning av poenget med å se på om kjøp av skytjenester gjennom integrator innebærer at det etableres en direkte avtale mellom en selv som kunde og skyleverandøren eller ei, så bør det også vurderes å bygge ut bilag 10 til å omfatte mer enn kun kopi av skytjenestevilkårene. Vår anbefaling er som minimum å også bruke bilag 10 til å finne ut om avtalemodeller innebærer direkteavtale eller ei med skyleverandør. Det bør således være en placeholder for dette i bilag 10, hvor tilbyder bør redegjøre for dette. Litt avhengig av svaret så kan en da også vurdere om en for eksempel blir GDPR compliant. Vi ser veldig mange eksempler på videresalgsmodeller innenfor SaaS anskaffelser til eksempel, hvor det ikke blir en direkte avtale mellom sluttkunde og plattformleverandør. Da blir det heller ingen databehandleravtale mellom disse, og påkrevd SCC mangler i de fleste tilfeller for å gi et eksempel. Her er det mange andre fallgruver som en også bør sette seg inn i. Videre bør en også vurdere å bygge ut bilag 10 slik at en i større grad kan evaluere «godheten» i avtalebetingelsene for de ulike skyleverandørene som tilbys, slik at en kan foreta et valg også basert på dette.
- En siste større ting som en bør vurdere som kunde ved bruk av avtalen er hvorvidt en er tjent med å opprettholde standardavtalens reguleringer av integrators rådgivningsplikt rundt endring i skytjenestevilkår, compliance osv. Som nevnt over legger avtalens pkt. 1.1.2 opp til at integrator som hovedregel skal håndheve standardvilkårene ovenfor skytjenesteleverandøren på vegne av kunden. Bestemmelser som pkt. 2.3.1, 2.3.5.2, 2.3.4 og 2.4.4 oppstiller videre en plikt for integrator til å overvåke endring i skytjenestene og i skytjenestevilkårene og varsle kunden om dette, holde oversikt over bestillinger, forbruk mv, legge til rette for at kunden får tilgang til den informasjon kunden trenger fra skyleverandøren, følge opp databehandleravtalen mellom skyleverandør og kunden på kundens vegne m.v. Pkt. 7.2.3 oppstiller en plikt for integrator til å påse at skytjenestene tilfredsstiller ufravikelige lovkrav (spesifisert i bilag 1 av kunden) og varsle kunden om det endrer seg, samt påse at skytjenesten ivaretas tilstrekkelig sikring av kundens data. Alle disse rådgivningspliktene til integrator er forståelige fra et kundeperspektiv, men vi vil likevel advare mot å ta med samtlige av disse omfattende pliktene uten videre.
Kan ekskludere mindre tilbydere
Spesielt plikten til å innestå for at kundens bruk av skytjenesten er compliant med lov krever at tilbyder har omfattende juridisk kompetanse tilgjengelig for å kunne svare ut dette. For eksempel at bruk av skytjenesten er compliant for helseforetak, for banker og forsikringsselskap i relasjon til EBA og EIOPA regler, for kraftselskap i relasjon til NVE reglene osv. Vår spådom er at dette rett og slett vil ekskludere mange av de mindre tilbyderne, da de ikke har økonomisk kapasitet til å grave i dette i mange ulike tilbud med kunder i mange ulike bransjer. Også flere av de store IT-selskapene vil også kunne ha problem med å si ja til et slikt ansvar. Vår klare anbefaling er derfor å vurdere disse pliktene nøye og vurdere å justere dem noe, for å sikre at en ikke mister potensielle tilbydere, eller som offentlig kunde måtte avvise ellers gode tilbydere som tar forbehold til dette. Som kunde kan en for eksempel vurdere å gjøre disse vurderingene internt istedenfor, og heller stille konkrete funksjonelle, tekniske og sikkerhetsmessige krav til Leverandørens ytelse, som Leverandøren konkret kan svare opp og komme med sine råd rundt.
Det kommenteres også at plikten i avtalens pkt. 1.1.2 til at integrator skal håndheve standardvilkårene ovenfor skytjenesteleverandøren på vegne av kunden bør vurderes nøye. For det første er det ikke veldig tydelig hva det betyr å «håndheve» standardvilkårene. For å unngå forventningsgap på kunde- og integratorsiden så bør dette detaljeres ut i for eksempel en RACI som inntas i bilag 1 (evt. Forvaltningsdokumentet avtalens pkt. 2.3.1 legger opp til). Som kunde bør en også ta stilling til om en egentlig ønsker at integrator skal forvalte avtalen mot skytjenesteleverandøren på kundens vegne. Vår klare oppfatning selv som rådgiver på kundesiden er at leverandørsiden er gode på å skjønne ulike skytjenester og prismodeller, men ikke kontraktuelle rettigheter og forpliktelser for øvrig i skyvilkårene. Vi ville således aldri anbefalt noen av våre kunder å overlate forvaltningen av skyvilkårene til en integrator fullt og helt, men i høyden la de være «mellommann» i utvalgt dialog, for eksempel rundt å følge opp standardisert prisavslag, melde feil i skytjenesten o.l.
Dette er de viktigste «findings» vi har sett så langt. Det er en god del forhold av mindre karakter som en også bør vurdere å endre, men som med enhver standardavtale fra DFØ så bør en uansett vurdere om alle mekanismer blir riktige i den enkelte anskaffelse, og foreta nødvendige justeringer. Samt lage gode bilag. Oppsummeringsvis - SSA-Sky er et godt malverk å ta utgangspunkt i ved komplekse skyanskaffelser, men en bør som kunde vurdere ovennevnte temaer nøye ved anskaffelse av «public cloud» tjenester, for å sikre god konkurranse og gode tilbud.
