Rettighetsadvokater
Spesialiserte Advokater

SSA-L (Løpende tjenestekjøp) – avtalen for skytjenester og «as-a-service»

Tre mennesker sitter i et møte. Foto

SSA-L er Statens standardavtale for løpende tjenestekjøp, og passer for kjøp av skytjenester og andre «as-a-service»-leveranser (SaaS, PaaS, IaaS). Avtalen regulerer tjenestebeskrivelse, SLA/tilgjengelighet, sikkerhet og personvern, fakturering/abonnement, endringer og avslutning/portabilitet. Den brukes når kunden kjøper en standardisert tjeneste som leveres kontinuerlig, ikke et engangsprodukt. Riktig bruk av SSA-L gir forutsigbarhet i ytelse, kostnad og risiko – og færre konflikter.

 

Artikkelen er skrevet og kvalitetssikret av Codex Advokat sitt team for teknologi- og kontraktsrett.

Få hjelp med SSA-L 22 93 38 50
av Codex Advokat
08/09/2025

Kort oppsummert

  • SSA-L brukes for løpende tjenestekjøp – typisk skytjenester (SaaS, PaaS, IaaS).
  • Avtalen fokuserer på SLA/tilgjengelighet, support, sikkerhet/personvern og portabilitet ved avslutning.
  • Egner seg når leveransen er standardisert og kontinuerlig; ikke et engangsprosjekt.
  • For utvikling/tilpasning brukes SSA-T (fast krav) eller SSA-S (smidig). For driftstjenester: SSA-D. For rene kjøp: SSA-K.
  • Gode bilag (tjenestebeskrivelse, ytelse, endringer, sikkerhet) avgjør kvaliteten på avtalen.

Hva er SSA-L – og når passer den?

SSA-L dekker kjøp av løpende tjenester der leverandøren holder en tjeneste tilgjengelig for kunden over tid – ofte gjennom skyplattformer. Tjenesten er gjerne standardisert, med definerte nivåer for oppetid, responstid og kapasitet. Dette kan være alt fra forretningsapplikasjoner (SaaS), plattform-/databaseleveranser (PaaS) til infrastruktur (IaaS).

Kjennetegn ved avtaler som passer SSA-L:

  • Kontinuerlig leveranse (abonnement) fremfor enkeltstående prosjektleveranse.
  • Standardisert funksjonalitet – kunden kjøper tilgang, ikke eierskap.
  • Målelige SLA-er (tilgjengelighet, responstid, feilretting).
  • Tydelig avslutnings- og tilbakeleveringsprosess (datarettigheter/portabilitet).

Når passer SSA-L ikke?

  • Ved utvikling/tilpasning av programvare med definert krav → SSA-T.
  • Ved smidige utviklingsprosjekter med iterasjoner → SSA-S.
  • Ved drift på kundens vegne (forvaltning av applikasjoner/infrastruktur) → SSA-D.
  • Ved engangskjøp av programvare/utstyr → SSA-K.

Slik bygger du en robust SSA-L-kontrakt

1) Tjenestebeskrivelse og SLA som kan måles

Kjernen i SSA-L er en presis tjenestebeskrivelse. Beskriv hva kunden faktisk får: moduler, kapasitet, lokasjoner/regioner, støttekanaler, planlagt nedetid og oppgraderingsregime. Legg inn SLA med objektive måleparametere:

  • Tilgjengelighet (f.eks. 99,9 % pr. måned).
  • Responstid på feil (kritisk, høy, medium, lav).
  • Feilretting (MTR/MTTR der det er relevant).
  • Kredittordning ved SLA-brudd (tjenestekreditter eller prisavslag).

2) Endringer og veikart

Skyleverandører utvikler tjenestene fortløpende. Reguler hvordan endringer varsles, hvilken påvirkning de kan ha på funksjon, ytelse, integrasjoner og pris – og kundens rettigheter ved uønskede endringer (for eksempel rett til å motsette seg, få overgangsperiode eller si opp uten gebyr).

3) Sikkerhet, etterlevelse og personvern

  • Sikkerhetsnivå: tekniske og organisatoriske tiltak, sertifiseringer (f.eks. ISO 27001), logging/tilgangsstyring.
  • Personvern: rollefordeling (behandlingsansvarlig/databehandler), databehandleravtale, overføring til tredjeland, underleverandører, revisjonsrett.
  • Hendelseshåndtering: deteksjon, varsling, frister, innhold i avviksrapporter.

4) Datarettigheter, portabilitet og exit

Definér at kunden eier egne data. Beskriv format, API-er og frister for uthenting/sletting ved opphør. Avklar kostnad/ansvar for bistand ved migrering. Sørg for at leverandøren sletter rester etter bekreftet overføring, og at dette dokumenteres.

5) Vederlag og prisjustering

Abonnement, bruk/forbruk, trinnvise nivåer – eller en kombinasjon. Klargjør når pris kan justeres (indeks, ny modul, forbruk), hvordan det varsles, og hvilke rettigheter kunden har ved vesentlige endringer.

💡 Visste du at?
Små presiseringer i SLA-definisjoner (måleperiode, eksklusjoner, planlagt vedlikehold) er ofte nok til å unngå de mest vanlige SLA-tvister.

Trenger du hjelp med SSA-L?

Send oss en henvendelse under, så tar vi kontakt:

Forskjellen på SSA-L og SSA-D (drift)

Mange blander løpende tjenestekjøp og driftstjenester. En tommelfingerregel:

  • SSA-L: Leverandøren stiller en standard tjeneste til rådighet (typisk multi-tenant sky). Kunden kjøper tilgang.
  • SSA-D: Leverandøren drifter kundens spesifikke løsning/miljø, gjerne med dedikert oppsett, operasjonelle rutiner og skreddersøm.

Har du en leveranse som både krever standard skytjeneste og forvaltning av din applikasjon? Det kan bety SSA-L + SSA-D – eller SSA-L med særskilte driftstillegg hvis modellen tillater det. Poenget er å speile realiteten i kontraktene, ikke bare navnet på tjenesten.

Typiske fallgruver – og hvordan du unngår dem

  1. Utydelig tjenestebeskrivelse. List moduler, kapasiteter, datalokasjoner, integrasjoner og begrensninger.
  2. SLA uten praktisk effekt. Bruk målbare parametere, realistiske responser, og kreditt-/avkortningsregler.
  3. Ingen exit-plan. Avtal dataformat, API-tilgang, frister, kostnader og slettesertifikat ved opphør.
  4. Personvern på autopilot. Konkret databehandleravtale, underleverandører, overføring, sikkerhetstiltak og revisjonsrett.
  5. Endringer uten grenser. Varslingsfrist, akseptkriterier, konsekvensvurdering (pris/tid/kvalitet) og rett til oppsigelse.
  6. Dobbelregulering med andre SSA-er. Avklar grensesnitt mot SSA-T/SSA-S (utvikling), SSA-D (drift) og SSA-K (engangskjøp).

💡 Visste du at?
En enkel endringslogg (dato, beskrivelse, virkning, beslutning) senker tvistenivået dramatisk i løpende kontrakter – fordi partene husker hva som ble avtalt, når og hvorfor.

Slik går du frem

  1. Avklar leveransemodellen: er dette standard tjeneste (SSA-L), drift (SSA-D) eller utvikling (SSA-T/SSA-S)?
  2. Skriv tjenestebeskrivelsen først: funksjon, begrensninger, integrasjoner, regioner.
  3. Legg på SLA/Sikkerhet/Personvern som kan måles og etterprøves.
  4. Planlegg exit fra dag 1: portabilitet, format, frister, sletting.
  5. Knyt pris til verdi: abonnement + forbruk, klare regler for justeringer.

Jo tidligere du får dette på plass, desto enklere blir forhandling, styring og ivaretakelse av risiko.

Få hjelp med SSA-L 22 93 38 50

Ofte stilte spørsmål om SSA-L (løpende tjenestekjøp)

Hva er SSA-L?

SSA-L er Statens standardavtale for løpende tjenestekjøp, særlig egnet for skytjenester (SaaS, PaaS, IaaS) og andre «as-a-service»-leveranser.

Når bør jeg bruke SSA-L i stedet for SSA-D?

Bruk SSA-L når du kjøper en standardisert tjeneste levert kontinuerlig. Bruk SSA-D når leverandøren drifter ditt spesifikke miljø eller applikasjoner på dine vegne.

Kan SSA-L kombineres med andre SSA-avtaler?

Ja. Den kombineres ofte med SSA-T/SSA-S for utvikling og med SSA-V for vedlikehold. Sørg for tydelige grensesnitt for å unngå dobbelregulering.

Hva bør en SSA-L inneholde om SLA?

Målbare nivåer for tilgjengelighet, responstid og feilretting, samt kreditt- eller avkortningsregler ved avvik – og definisjoner av måleperiode og unntak.

Hvordan regulerer jeg personvern i SSA-L?

Bruk databehandleravtale, beskriv underleverandører, overføring til tredjeland, sikkerhetstiltak og rett til revisjon. Avklar hendelses- og varslingsrutiner.

Hva betyr portabilitet i SSA-L?

At kunden kan hente ut data i et avtalt format innen en frist ved opphør, og at leverandøren deretter sletter rester med dokumentert bekreftelse.

Hvordan styres pris i en SSA-L?

Avtalen kan ha abonnement, forbruk eller en kombinasjon. Avklar når pris kan justeres, varslingstid og kundens rettigheter ved vesentlige endringer.