Direktoratet for forvaltning og økonomistyring (DFØ) har publisert oppdaterte versjoner av flere av Statens standardavtaler (SSA). Selv om formålet ikke har vært å innføre større endringer, er det flere viktige justeringer som kan påvirke offentlige og private aktører i anskaffelsesprosesser for IT- og konsulenttjenester.
Oppdateringene i Statens standardavtaler (SSA) ble publisert før sommeren som en del av en planlagt prosess i forbindelse med DFØs overtakelse av forvaltningen av SSA i september 2020. Seks ulike standardavtaler har blitt oppdatert:
- Bistands- og oppdragsavtalen: SSA-B og SSA-B-enkel
- Driftsavtalen: SSA-D
- Kjøpsavtalen: SSA-K
- Oppdragsavtalen: SSA-O
- Utviklings- og tilpasningsavtalen: SSA-T
- Vedlikeholdsavtalen: SSA-V
Ifølge DFØ, har formålet med oppdateringen vært å gjennomføre mindre språklige og tekniske endringer for å gjøre avtalene mer brukervennlige, harmoniserte, oversiktlige og i tråd med gjeldende regelverk. Under gir vi en oppsummering av de mest sentrale endringene.
Oppdatering av endringsregler i SSA-T, SSA-D
Innskrenket "hoppeplikt" – kundens rett til å kreve endringer gjennomført
De nye utgavene av SSA innskrenker "hoppeplikten", dvs. leverandørens plikt til å levere på kundens "pålegg" om endring av tjenesten som bl.a. finnes i SSA-T og SSA-D kapittel 3.
Innskrenkingen fastslår at kunden ikke kan kreve endringer som av "tekniske grunner" ikke kan gjennomføres uten at leverandøren også endrer sin "standard plattform" eller "standard tjenester" som "også leveres til andre kunder". Innskrenkingen ble innført allerede ved publikasjonen av SSA-SKY i 2021 og er følgelig ikke ny i SSA-serien, men har nå blitt inkorporert i SSA-D og SSA-T. Ordlyden er imidlertid vid, og vi ser en risiko for at bestemmelsen vil kunne påberopes i utilsiktede situasjoner. Vi har redegjort for noen tenkte eksempler som illustrerer problemstillingen nedenfor.
Eksempel: "Ekte SaaS" vs. "Fake SaaS"
Innskrenkingen av endringsretten ivaretar hensynet til leverandører av skalerbare løsninger og delte tjenester. Dette er typisk ved "multi tenant" løsninger hvor flere kunder bruker samme installasjon av applikasjonen eller plattformen. I slike leveranser vil en endring av tjenesten hos én kunde potensielt ramme funksjonalitet tilgjengeliggjort for alle kunder.
Innskrenkingen av endringsretten vil imidlertid også kunne ramme "fake SaaS"-leveranser. Dette er tilfeller hvor en programvareleverandør tilbyr en applikasjon (typisk) driftet via skyinfrastruktur til kunder som en "single tenant" løsning. I slike tilfeller blir applikasjonen levert som en spesifikk kundeinstallasjon og ikke til flere kunder som bruker samme installasjon. Leveransemodellen er ikke iboende problematisk, men ved å klassifisere tjenesten som "SaaS" blir leveransen gjerne omtalt som "fake SaaS", da SaaS-modellens kjerneegenskaper ikke er oppfylt.
Ved "fake SaaS" vil kundens endringsforespørsel potensielt påvirke standardprogramvaren i applikasjonen eller plattformen som også benyttes av andre kunder. Selv om standardprogramvaren forvaltes på en konkret kundeinstallasjon, vil ikke endringen, til forskjell til ved ekte SaaS, automatisk bli implementert på leverandørens øvrige kundeinstallasjoner. Med andre ord vil leverandøren av "fake SaaS" også kunne motsette seg endringsordren fra kunden med henvisning til den nye ordlyden i SSA-D og SSA-T. På denne måten risikerer kunden å måtte forhandle fritt om implementering av potensielt forretningskritisk funksjonalitet uten beskyttelse av en håndhevbar og ensidig endringsrett.
Innholds- og prosessregler
Statens standardavtaler har videre flyttet innholds- og prosessregler knyttet til endringshåndtering i kapittel 3 ut fra avtaleteksten og inn i bilagene. Følgelig er frister for endringsutredning/overslag ikke lenger å finne i den generelle avtaleteksten. Også innholdskravene til slike endringer er nå å finne i standardbilagene og ikke i hovedavtalen.
Vi antar at endringene har kommet som en respons på at det har vist seg å være uhensiktsmessig at standardavtalene tidligere har vært preskriptive for operasjonelle prosesser, som i praksis kan variere fra leverandør til leverandør. Markedet har som en følge av dette i stor grad uansett fraveket de gamle reglene om innhold og frister for endringsordre i bilagene.
Trepartskonstellasjon
Endringene fortsetter den generelle utviklingen vi har sett i tidligere oppdateringer av avtalemalene med ytterligere klargjøring av ansvarsforholdet mellom kunde, leverandør og tredjepartsleverandør av standardprogramvare.
I SSA-T, har DFØ konkretisert at ved lisensvilkår inngått mellom kunde/tredjepartsleverandør som angår løpende abonnementstjenester ("as-a-service"), skal abonnementets varighet og oppsigelsesbestemmelser avtales i bilag 4, og prisen i bilag 7.
Endringen reflekterer økt bruk av tredjepartsleveranser i form av skytjenester istedenfor mer tradisjonell programvare installert hos kunden eller kundens driftsleverandør i forbindelse med gjennomføring av implementeringsprosjekter.
Tredjepartsavtaler er regulert som selvstendige avtaler mellom kunden og leverandør av standardprogramvare eller tjenester, og skal eksempelvis inntas i bilag 10 av SSA-T. Kundens avtalemotpart i slike avtaler anses ikke som underleverandør, og hovedleverandøren etter SSA-T er i utgangspunktet ikke forpliktet etter tredjepartsavtalen som vedlegges bilag 10. Ved å plassere tredjepartsavtalen utenfor leverandørens ansvar, skal leverandøren slippe å bære risiko for realytelser som leverandøren i utgangspunktet ikke råder over.
Til sammenligning er leverandøren fullt ut ansvarlig for ytelser fra en underleverandør etter SSA-T. Leverandøren må følgelig kontrollere risiko for underleverandørens mislighold ved å inngå en egen avtale med underleverandøren (typisk såkalt "back-to-back"-avtale), samt evt. beregne inn risikomargin og kostnader knyttet til håndtering av underleverandørrisiko i prisingen rettet mot kunden etter avtalen.
Konseptet med tredjepartsavtaler ble relativt nylig innført i SSA (se bl.a. SSA-D 2015). Ved innføringen fikk kunden mulighet å gå ut i markedet med en konsolidert kravspesifikasjon som leverandøren i sin løsningsbeskrivelse bærer risiko for å spalte opp mellom hhv. standardløsning/tredjepartsleveranse og egen leveranse/ansvar i bilagene.
Systematikken er fornuftig i mange tilfeller, men leverandørsiden løper risiko dersom leverandøren upresist definerer grensen mellom egen ytelse og tredjepartsytelse i bilagene til SSA-T. Selv om leverandøren ofte er nærmere til å gjøre en slik grensedragning, kan denne opplysningsplikten slå feil ut. Et eksempel er når tredjepartsleveransen er lagt inn som en forutsetning i avtalen på forhånd fra kundesiden uten at krav som er rettet mot tredjepartsleveransen er tatt ut av kravspesifikasjonen.
Videre fastslår SSA-T (mellom hovedleverandør og kunde) punkt 1.3 om "tolkning – rangordning" at tredjepartsavtalen (mellom tredjepart og kunde) er bindende "ovenfor Kunden når det gjelder krav til levering av standardprogramvare".
Ordlyden kan (satt på spissen) reise spørsmålet: Hva med øvrige krav som følger av tredjepartsavtalen?
En antitetisk tolkning kan eksempelvis tilsi at restforpliktelsen i bilag 10 absorberes av hovedleverandøren, slik at hovedleverandøren blir ansvarlig for å levere eventuelle restforpliktelser overfor kunden. Etter vår vurdering bør grensedragningen mellom hovedleverandør og kunde og tredjepartsavtaler være klarere. Uklarhet i denne grensedragningen vil ofte skape friksjon i anskaffelsesprosesser og kan få en konsekvens for både leverandørmarkedets interesser i å inngi tilbud, samt prisene som kunder får tilbudt i markedet.
Kundemedvirkning
Krav til kundens medvirkning er presisert i de nye utgavene av SSA.
SSA-T tilføyer blant annet at kunden skal gi "nødvendige tilganger", samt sørge for at kundens "øvrige leverandører gir nødvendig informasjon og tilgang" til leverandøren, jf. punkt 5.1.3. I tillegg er det angitt krav til at kunden skal påse at egne ressurser har "nødvendig kompetanse", jf. punkt. 5.2.2. Disse presiseringene kommer i tillegg til avtalens generelle krav til at kunden skal "legge forholdene til rette for at Leverandøren skal få utført sine plikter etter denne avtalen", jf. punkt 5.1.3 som er videreført fra tidligere versjoner.
Manglende kundemedvirkning er en nøkkelrisiko i implementeringsprosjekter som SSA-T typisk regulerer. Endringen kan potensielt ses i lys av nyere rettspraksis hvor kundesidens hevingsrett har gått tapt, bl.a. som følge av manglende medvirkning. Se bl.a. LB-2020-82571 (Grindgut), og LE-2018-76187-3 (Felleskjøpet).
Endringen er isolert sett ukontroversiell og godt begrunnet. Vår vurdering er imidlertid at SSA, ved å angi en vid og diskresjonær medvirkningsplikt, øker begge parters risiko for manglende reell medvirkning fra kundesiden. Vide medvirkningskrav gir leverandøren omfattende adgang til å påberope seg manglende medvirkning som ansvarsfraskrivelse ved eget mislighold. Dette framprovoserer i mindre grad proaktiv atferd fra leverandøren gjennom varsling og presis kravstilling til kundens medvirkning før avtaleinngåelse og når prosjekter møter utfordringer. Følgelig øker risikoen for at begge parter går inn i prosjektet med uavklarte forventninger til begge parters roller og ansvar.
Informasjonssikkerhet
I tidligere versjoner av SSA framgikk det bl.a. informasjonssikkerhetskrav om at leverandører pliktet å atskille kundedata fra tredjeparters data. Kravet om atskillelse ble presisert som "nødvendige tekniske tiltak som sikrer data mot uønsket endring og innsyn" (se bl.a. SSA-D 2018 punkt 9.2) . Bestemmelsen reiste tolkningstvil om fysisk eller logisk atskillelse var pålagt for etterlevelse av avtalens krav.
I de oppdaterte 2024-versjonene av SSA, er kravet om å atskille kundedata fra tredjeparters data fjernet.
Endringen reflekterer at DFØ formodentlig har konkludert med at det ikke er passende å stille preskriptive krav på dette området i generelle avtalemaler. SSA forholder seg nå til generelle informasjonssikkerhetsnormer og krav om implementering av forholdsmessige tiltak. Dette innebærer at kunder som har krav til atskillelse av data i større utstrekning må formulere slike krav i bilag 1.
Databehandleravtale
I 2015-versjonene av SSA ble henvisninger til databehandleravtaler først introdusert som eventuelle tillegg som partene "kan" ha inngått ved siden av tjenestene som regulert av SSA.
I 2018-versjonene av SSA ble databehandleravtaler regulert som pålagt ved behandling av personopplysninger. I denne systematikken ble imidlertid databehandleravtalen behandlet utenfor avtalens ramme.
I 2024 versjonene av SSA har databehandleravtaler fått en egen posisjon som bilag til SSA. Bilagsmalene inneholder en mal til databehandleravtale og hovedavtalens regulering omkring behandling av personopplysninger har blitt tilsvarende forenklet.
Rettigheter til data
Ved oppdateringene i 2024 innfører SSA en egen bestemmelse om rettigheter til data.
Rettighetsbestemmelsen fastslår kundens rettigheter til all data som samles inn, overføres, bearbeides, lagres eller på annen måte behandles etter SSA.
Leverandøren gis en begrenset rett til behandling av data for å oppfylle forpliktelser etter avtalen. SSA presiserer at leverandøren ikke under noen omstendighet har rett til å utøve tilbakeholdsrett i kundens data.
Rettighetsbestemmelsene er i tråd med kjent kontraktpraksis i markedet og framstår som fornuftige presiseringer.
Leverandøren gis videre rett til bruk av aggregert, anonymisert data til å forbedre egne tjenester.
Dette kan erfaringsmessig reise problemstillinger ved behandling av industriell-/produksjonsdata. Slik data vil ofte være anonym og kan avsløre sensitive tema om en kunde i aggregert form. Kunder vil kunne ha en berettiget interesse i å underlegge slik data strengere konfidensialitet av både konkurransehensyn og andre kommersielle hensyn. Dette gjelder særlig i tilfeller hvor leverandøren og kunden står i konkurranseforhold.
Kunder må nå ta uttrykkelig forbehold i bilag 1 eller endringskatalogen for å frata leverandører rett til bruk av aggregert, anonymisert data til å forbedre egne tjenester.
Lønns- og arbeidsvilkår
Kravene til lønns- og arbeidsvilkår under offentlige kontakter har blitt utvidet, og det er lagt til klare sanksjoner ved leverandørens brudd på kravene. Dersom leverandøren eksempelvis ikke overholder den tilhørende dokumentasjonsplikten, løper en dagbot på minimum NOK 1500 per dag.
Ta gjerne kontakt med oss dersom du ønsker hjelp til å gjennomføre IT anskaffelser ved bruk av SSA i privat og offentlig sektor.