IT-kontrakter: Hva bør de inneholde?
En IT-kontrakt brukes når virksomheter inngår avtaler om utvikling, kjøp eller drift av IT-systemer – uten å bruke Statens standardavtaler (SSA). I private prosjekter benyttes ofte egne kontrakter eller bransjestandarder (f.eks. IKT Norge, Dataforeningen). En IT-kontrakt bør alltid regulere funksjonalitet, rettigheter, testing, pris, levering og tvisteløsning. Riktig kontrakt reduserer risiko for konflikt og sikrer kontroll over immaterielle rettigheter.
Artikkelen er skrevet og kvalitetssikret av Codex Advokat sitt team for teknologi- og kontraktsrett.
Kort oppsummert
- IT-kontrakter brukes ofte i private prosjekter der SSA ikke er aktuelt.
- Avtalene bør regulere funksjonalitet, endringer, rettigheter, pris og tvisteløsning.
- Mange benytter standardavtaler fra IKT Norge eller Dataforeningen.
- Et kritisk punkt er rettigheter til kildekode og videre bruk.
- Våre advokater hjelper med utarbeidelse, forhandling og tvisteløsning.
Hva er en IT-kontrakt?
En IT-kontrakt er en juridisk bindende avtale mellom kunde og leverandør om utvikling, tilpasning, kjøp eller drift av IT-systemer. Mens Statens standardavtaler (SSA) er mye brukt i offentlig sektor, velger mange private aktører egne kontraktsmaler.
Dette kan være:
- Egendefinerte kontrakter tilpasset prosjektet.
- Bransjestandarder fra for eksempel IKT Norge eller Den norske dataforening.
- Enkle bestillingsavtaler kombinert med tilbud/e-postkorrespondanse – noe som ofte fører til tvister.
💡 Visste du at?
De fleste konflikter i IT-prosjekter oppstår fordi avtalen er for utydelig – ikke fordi partene egentlig er uenige om intensjonene.
Når bør du bruke IT-kontrakt i stedet for SSA?
SSA passer godt for offentlige prosjekter, men private virksomheter trenger ofte større fleksibilitet. Typiske tilfeller hvor IT-kontrakt utenfor SSA er riktig valg:
- Prosjekter der kundens behov er unike og krever skreddersøm.
- Når partene ønsker å forhandle bort fra SSA-standardene.
- Små prosjekter der SSA blir for omfattende.
- Internasjonale leveranser hvor SSA ikke er kjent eller akseptert.
- Når leverandøren har egne standardvilkår (f.eks. SaaS eller lisensavtaler).
Hva bør en IT-kontrakt inneholde?
En god IT-kontrakt bør alltid regulere:
- Beskrivelse av leveransen: Funksjonalitet, design, grensesnitt, integrasjoner og krav til dokumentasjon.
- Endringer i prosjektet: Prosess for endringsordre, konsekvenser for tid og pris.
- Testing og akseptanse: Hvordan løsningen skal testes, frister for tilbakemelding og hva som kreves for godkjenning.
- Rettigheter til kildekode og immaterielle verdier: Skal kunden ha full eiendomsrett, eller kun bruksrett? Har leverandøren rett til gjenbruk?
- Pris og betaling: Fastpris, timepris eller milepælsbasert fakturering. Eventuell prisjustering.
- Levering og milepæler: Datoer, del-leveranser og konsekvenser ved forsinkelser (dagbøter).
- Support og vedlikehold: Retting av feil, videreutvikling, sikkerhetsoppdateringer.
- Mislighold og oppsigelse: Konsekvenser ved brudd på avtalen, rett til heving, erstatning eller dagbøter.
- Tvisteløsning: Avtalt verneting, eventuell voldgift, eller bruk av mekling før rettssak.
💡 Visste du at?
Mange leverandører forbeholder seg retten til å gjenbruke kode de har utviklet – noe som kan gi kunden mindre kontroll enn forventet.
Trenger du hjelp med IT-kontrakter?
Send oss en henvendelse under, så tar vi kontakt:
Standardavtaler fra IKT Norge og Dataforeningen
Når partene ikke bruker SSA, velger mange i stedet:
- IKT Norge-avtalene: Standardiserte kontrakter tilpasset private IT-prosjekter.
- Dataforeningens avtaler: Brukt i utviklingsprosjekter, særlig innen programvare.
Disse avtalene kan være gode utgangspunkt, men bør alltid tilpasses det konkrete prosjektet. Ingen standardavtale dekker alt.
Vanlige feil i IT-kontrakter
- Avtalen består kun av en bestilling eller e-postkorrespondanse.
- Immaterielle rettigheter er ikke regulert – hvem eier egentlig kildekoden?
- Ingen akseptanseprosess – partene er uenige om når leveransen er ferdig.
- Endringer håndteres uformelt – og blir kilder til konflikt.
- Milepæler og dagbøter er utelatt – noe som svekker kundens posisjon ved forsinkelse.
Slik går du frem
- Avklar type avtale: SSA eller IT-kontrakt utenfor SSA.
- Lag en detaljert beskrivelse av leveransen.
- Avtal rettigheter til kildekode og dokumentasjon.
- Sikre akseptanse, testing og milepæler.
- Avtal konsekvenser ved brudd – ikke vent til konflikten oppstår.
Jo tidligere kontrakten er på plass, desto enklere blir prosjektet å styre.
Ofte stilte spørsmål om IT-kontrakter (utenfor SSA)
Hva er en IT-kontrakt?
En IT-kontrakt er en avtale om utvikling, kjøp, tilpasning, drift eller forvaltning av IT-løsninger i private prosjekter der SSA ikke brukes.
Når bør jeg bruke IT-kontrakt i stedet for SSA?
Når prosjektet er privat, lite, internasjonalt eller krever fleksibilitet som SSA ikke gir, eller når leverandøren har egne vilkår (f.eks. SaaS).
Hva bør en IT-kontrakt inneholde?
Leveransebeskrivelse, endringsordre, testing/akseptanse, IP-rettigheter, pris/vederlag, milepæler, support/vedlikehold, mislighold og tvisteløsning.
Hvem eier kildekoden i en IT-kontrakt?
Det må avtalefestes. Kunden kan få eiendomsrett eller bruksrett; leverandøren kan beholde gjenbruksrett til egne komponenter.
Hvordan regulerer vi endringer underveis?
Bruk en skriftlig endringsprosess: forespørsel → konsekvensvurdering (tid/kost/kvalitet) → beslutning innen frist og oppdatert endringslogg.
Hvordan testes og godkjennes leveransen?
Avtal konkrete akseptansekriterier, testplan og frister. Stilletiende godkjenning kan brukes der det er forsvarlig.
Hvordan settes pris – fastpris, timepris eller målpris?
Velg modell etter risiko: fastpris ved klart omfang, målpris ved usikkerhet, timepris med tak for smale leveranser. Knytt betaling til milepæler.
Kan vi avtale dagbøter ved forsinkelse?
Ja, dagbøter kan avtales for å sikre fremdrift. Definér startpunkt, nivå og samlet tak.
Hvordan håndteres personvern og sikkerhet?
Legg ved databehandleravtale ved behandling av personopplysninger. Avklar sikkerhetstiltak, underleverandører, hendelseshåndtering og revisjonsrett.
Hva med support, vedlikehold og SLA?
Avtal responstider, feilklasser, tilgjengelighet, vedlikeholdsvinduer og kompensasjon ved avvik (kreditter/avkortning).
Hvordan sikrer vi exit og portabilitet?
Beskriv dataeierskap, format/API for uttrekk, frister, bistand ved migrering og slettesertifikat ved opphør.
Finnes det maler for IT-kontrakter?
Ja, bl.a. fra IKT Norge og Den norske dataforening. Maler må tilpasses prosjektet – ingen standard dekker alt.
Hvordan løser vi tvister mest effektivt?
Avtal mekling først, deretter voldgift eller ordinær domstol. Presise bilag reduserer tvister betydelig.