4.1 Innledning

Vår hovedfokus er på den mer praktiske håndteringen av exit-situasjoner, men vi vil for ordens skyld kort angi hvilke sentrale regelverk som kan få betydning for exit-krav og -muligheter.

4.2 EUs personvernforording – GDPR

GDPR har ingen egen exit-regulering. Partene må derfor se på de generelle kravene i forordningen og forholde seg til mer fragmenterte bestemmelser.

Av størst betydning er GDPR artikkel 32: Sikkerhet ved behandlingen

• Skal gjennomføre egnede tekniske og organisatoriske tiltak for å oppnå et sikkerhetsnivå som er egnet med hensyn til risikoen,

• Skal treffe tiltak for å sikre at enhver fysisk person som handler for virksomheten, behandler nevnte opplysninger bare etter instruks fra den behandlingsansvarlige

Også i GDPR artikkel 28, som gjelder avtale mellom behandlingsansvarlig og databehandler, vil man finne ulike krav som vil ha en side til exit-håndtering:

• Den behandlingsansvarlige må «bare bruke databehandlere som gir tilstrekkelige garantier» som «oppfyller kravene i denne forordning og vern av den registrertes rettigheter». Dette vil fort innebære en plikt til å bytte ut leverandør som ikke kan oppstille slike garantier.

• Databehandler må følge instrukser «med hensyn til overføring av personopplysninger til en tredjestat». Dermed vil utleveringspålegg av en tredjestat fort kunne bryte med slike instrukser.

• Databehandleren «bistår den behandlingsansvarlige med å sikre overholdelse av forpliktelsene i henhold til artikkel 32-36». Dette har en side til hvorvidt det er mulig å ivareta krav om informasjonssikkerhet, som igjen vil ha betydning for exit og valg av leverandør.

• Databehandleren «sletter eller tilbakeleverer alle personopplysninger til den behandlingsansvarlige etter at tjenestene knyttet til behandlingen er levert». I forbindelse med en exit, vil slik oppfølging av databruk ha betydning ved overgang til en ny tjenesteleverandør.

• Varslingsplikt

4.3 Forordningen om digital operasjonell motstandsdyktighet i finanssektoren – DORA

Lov om digital operasjonell motstandsdyktighet i finanssektoren gjennomfører DORA-forordningen i norsk rett. DORA inneholder eksplisitte krav til exit-strategi.

Det følger av DORA artikkel 28 nr. 8 at det er krav til exit-strategi for finansielle enheters bruk av tjenester som støtter kritiske eller viktige funksjoner. Slike funksjoner har avgjørende betydning for den finansielle enhetens økonomiske prestasjon, tjenestestabilitet eller evne til å oppfylle plikter i lov eller forskrift, se artikkel 3 nr. 22.

Exit-strategiene skal ta hensyn til risiko. Kundens adgang til oppsigelse i forbindelse med situasjoner nevnt i art. 28 nr. 7, må ivaretas. Dette vil gjelde bl.a. situasjoner med vesentlig overtredelse av lover eller forhold som endrer funksjonene som tilbys. De finansielle enhetene skal sikre at de kan si opp kontraktsregulerte ordninger uten

• at deres forretningsvirksomhet avbrytes,

• at overholdelsen av de forskriftsmessige kravene begrenses, og

• at kontinuiteten og kvaliteten på de tjenestene som leveres til kunder, lider skade.

Exit-planene skal være omfattende og dokumenterte, og være tilstrekkelig testet samt være gjennomgått regelmessig. de skal, i samsvar med forholdsmessighetskriteriene fastsatt i DORA artikkel 4 nr. 2.

Krav til innholdet i kontraktene med IKT-tjenesteleverandørene følger av DORA artikkel 30 nr. 2 f. Exit-strategier skal være på plass, og særlig sørge for innføring av en obligatorisk passende overgangsperiode. Tredjepartsleverandøren av IKT-tjenester skal fortsette å levere de respektive funksjonene eller IKT-tjenestene i den aktuelle perioden, slik at den finansielle enheten kan bytte til andre eller interne løsninger.

Ytterligere krav følger av nivå 2-regelverk, særlig delegert kommisjonsforordning (EU) 2024/1773. Ifølge den nevnte rettsakten artikkel 10, skal det foreligge retningslinjer som inneholder krav om en dokumentert exit-plan. Det skal gjennomføres en periodisk gjennomgåelse og prøving av den dokumenterte exit-planen. Ved fastsettelse av exit-planen skal det tas hensyn til følgende:

• Uforutsette og vedvarende tjenesteavbrudd

• Uhensiktsmessig eller mislykket levering av tjenester

• Uventet oppsigelse av den kontraktsregulerte ordningen.

Exit-planen skal ifølge forordningen være realistisk, gjennomførbar og basert på plausible scenarioer og rimelige forutsetninger. Gjennomføringsplanen skal være forenlig med uttredelses- og oppsigelsesvilkårene som fastsatt i kontraktsregulerte ordninger.

4.4 NIS2-direktivet

NIS2 (direktiv (EU) 2022/2555) skal sørge for tiltak for å sikre et høyt felles nivå for sikkerhet i nettverks- og informasjonssystemer i EØS. NIS2-direktivet er ennå ikke gjort til norsk rett, men er ventet å bli gjennomført i nasjonal rett gjennom en lov om grunnsikring om ikke altfor lenge.

Selv om heller ikke dette direktivet er nedfelt eksplisitte krav om exit-håndtering, er det basert på en «all-hazards»-tilnærming, som er en form for risikohåndtering som krever at organisasjoner beskytter seg mot alle typer trusler, inkludert bl.a. ondsinnede angrep, menneskelige feil, systemsvikt og naturkatastrofer. Det er vanskelig å tenke seg at en slik tilnærming ikke inneholder planer eller avtaler for exit-håndtering.

Tiltakene for å ivareta informasjonssikkerhet er nedfelt i artikkel 21 nr. 2, og flere aspekter er nevnt i bokstav d, ved at den aktuelle virksomheten må ta hensyn til «sikkerhet i forsyningskjeden, herunder sikkerhetsrelaterte aspekter ved forholdet mellom hver enhet og dens direkte leverandører eller tjenesteleverandører».

Det europeiske byrå for nett- og informasjonssikkerhet, ENISA, har laget en Technical Implementation Guidance, som påpeker at det i forbinidelse med implementering av NIS2 bør laget (71) «exit strategies, in particular the establishment of a mandatory adequate transition period, provisions on intellectual property and responsibilities of the supplier during the exit period, for example to provide relevant documentation and historical logs.»

4.5 Anskaffelsesretten

Er kunden i tillegg underlagt anskaffelsesregelverket vil en exit-situasjon også innebære at tjenesten må konkurranseutsettes på nytt i en ny kunngjort konkurranse. Dette innebærer en ytterligere aktivitet som Kunden må planlegge for i tilfelle av exit. Skjer exit-situasjonen mer akutt finnes det riktignok hjemmel i anskaffelsesregelverket for å gjennomføre såkalte hasteanskaffelser jf. forskrift om offentlige anskaffelser § 13-3 bokstav e og § 13-3 a (direkte tildeling). Merk imidlertid at valg av leverandør basert på disse prosedyrene gjerne ikke gir grunnlag for en varig løsning, kun en midlertidig løsning frem til en ordinær konkurranse er gjennomført.

5.1 Innledning

Under vil vi gå gjennom ulike forhold vi anbefaler å regulere i en avtale mellom oppdragsgiver og skytjenesteleverandør for å sikre en hensiktsmessig exit-håndtering. Vi vil imidlertid ikke gå inn på den konkrete utformingen, ettersom det vil variere enormt og sprenge rammene for denne artikkelen.

5.2 Varsling ved krevende forhold og endringer i staten data befinner seg

Det følger allerede av blant annet GDPR at det skal varsles hvis f.eks. endrete politiske føringer kan skape større risiko for myndighetsinngrep og -overvåking.

Varslingen bør både skje innen en bestemt tidsfrist, f.eks. 48 timer fra tjenesteleverandøren fikk kunnskap om mulige endringer. Det bør også spesifiseres hva som skal være inntatt i varselet.

5.3 Dokumentasjon av alle prosesser rundt oppfølging av exit

Partene bør beskrive en tydelig, trinnvis exit-prosess med roller, ansvar og milepæler. Dette kan omfatte at leverandøren utarbeider og vedlikeholder en oppdatert exit-plan som dekker aktiviteter før, under og etter avvikling, inkludert beredskaps- og kommunikasjonsplan. Begge parter bør utpeke en «exit-leder». Starttidspunkt for exit-triggere eller kriterier for dokumentasjonsutforming. Oppdragsgiver bør kreve logging, journalføring og revisjonsspor for alle exit-aktiviteter.

5.4 Sletting av data

Slettemetoder kan nevnes, bl.a. sikker sletting i henhold til anerkjente standarder, inkludert overskriving, kryptografisk destruksjon for kryptert data og fysisk destruksjon der relevant. Omfang av sletteplikt kan tas med, bl.a. om leverandør skal slette data fra sikkerhetskopier, cache, logger, test- og utviklingsmiljøer, samt data hos underleverandører og i skytjenester mv.

Ansvar og roller bør også med: Hvem utfører, hvem verifiserer, og hvilke bevis skal leveres.

Det bør også være en mekanisme for å overholde lovpålagte oppbevaringskrav, med dokumentasjon av hva som ikke slettes og hvorfor.

Leverandøren kan levere en bekreftelse eller rapport som viser at sletting er utført i henhold til avtalen.

5.5 Migreringsperiode

Periodens lengde bør angis, ved at avtalen bør fastsette en minimumsperiode for migrering, tilpasset kompleksiteten i tjenesten. Avtalen bør regulere hvordan partene følger opp exit-prosessen, inkludert rapportering og kontrollmekanismer.

Leverandøren skal yte nødvendig bistand under migreringen, inkludert teknisk support og tilgang til systemer. Tilgjengelighet bør sikres også etter overføring, for eksempel ved å holde enkelte funksjoner operative i en overgangsperiode.

Tjenestekontinuitet er også sentralt å regulere, f.eks. fortsatt drift på uendret eller avtalt SLA‑nivå i overgangsperioden, inkludert beredskap, overvåkning og feilretting.

Tilgjengelighet og ressurser bør også vies plass. Det kan bl.a. avklares om oppdragsgiver skal følges opp av et dedikert team, hva slags kompetansekrav som er viktige, ulike former for tilgjengelighet (inkl. utvidede tidsvinduer), og forpliktelser til kunnskapsoverføring, workshops og teknisk støtte mot ny leverandør.

5.6 Priser i overgangsperioden og for exit-aktiviteter

Det må avtales priser for overgangsbistand og exit-aktiviteter, slik at kostnader er forutsigbare. Ofte kan leverandøren forsøke å få høyere priser i en migrasjons-/overgangsperiode.

Det kan være hensiktsmessig å si noe om prisstruktur: Skal det for eksempel være timepriser per rolle, faste pakker for definerte leveranser, volumpriser (per GB/uttrekk), eller egne beredskapspriser? Kostnadskontroll kan sikres ved forhåndsgodkjenning av arbeid, ikke‑overskridelsesklausul, tak pr. fase og krav om detaljerte timelister/leveranser. Mekanismer for å sikre konkurransedyktige vilkår ved forlengelse av overgang, er også relevante tiltak.

5.7 Håndtering av IP-rettigheter

Avtalen må avklare rettigheter vedrørende IP, herunder programvare, skript, malverk, integrasjonskomponenter, konfigurasjoner og dokumentasjon som utvikles eller tilpasses i kontraktsperioden. Oppdragsgiver bør sikres en tilstrekkelig bred bruksrett til nødvendige elementer for å videreføre virksomhetskritiske prosesser etter exit, inkludert rett til å bruke, kopiere, modifisere og drifte slike elementer hos ny leverandør eller internt. Eventuelle begrensninger knyttet til tredjepartsprogramvare og åpne lisenser må kartlegges og reguleres uttrykkelig, med leverandørens plikt til å skaffe nødvendige viderelisensieringer eller alternativer. Leverandøren skal ikke kunne hindre kunden i å bruke nødvendige elementer etter exit.

5.8 Tilbakelevering/tilgjengeliggjøring av data

En rekke aspekter knyttet til tilbakelevering av data kan reguleres. Det er avgjørende at leverandøren ikke kan slette kundens data kort tid etter en terminering av avtaleforholdet. Det er ikke uvanlig at standardvilkår inneholder bestemmelser om rask sletting etter opphør av avtalen.

Dersom dataene skal tilbekaleveres av leverandøren til kunden kan formatet som skal formidle data presiseres, og det kan være hensiktsmessig å benytte åpne og maskinlesbare formater. Er det i et uhensiktsmessig format, kan det koste mye å konvertere og overføre data.

Avtalen må presisere omfanget av data som skal tilbakeleveres, herunder forretningsdata, metadata, logger, dokumentasjon, konfigurasjoner, tilgangslister og historikk. Avtal også frister for tilbakelevering og kostnader for slik bistand.

5.9 Informasjonssikkerhet

Exit-prosessen må ivareta konfidensialitet, integritet og tilgjengelighet. Leverandøren bør dokumentere sikkerhetstiltak og bistå med nødvendige vurderinger (f.eks. DPIA/personvernkonsekvensvurdering) hvis det er relevant.

Ofte vil det være ulike personer og virksomheter som engasjeres for å sikre en smidig overgang. Det bør derfor være logger for all datauttrekk/sletting.

5.10 Oppsigelse

Avtal tydelige prosedyrer for oppsigelse, inkludert varslingsfrister og konsekvenser ved mislighold. Det bør etableres forutsigbare prosedyrer ved oppsigelse, herunder plikt for leverandøren til å yte overgangsbistand i en definert periode og til avtalte vilkår, slik at virksomhetskritiske tjenester kan videreføres uten avbrudd selv ved irregulær terminering. Konsekvenser ved mislighold bør omfatte rett til retting innen rimelig frist, dagbøter eller prisavslag ved vesentlige forsinkelser i exit, og adgang til å gjøre gjeldende tilbakeholdsrett på vederlag for ikke-leverte ytelser i tråd med gjeldende rett og kontrakt. Eventuelle begrensninger i leverandørens adgang til å terminere underleverandøravtaler som er kritiske for exit i oppsigelsesperioden bør beskrives, samt koordinering av termineringstidspunkter for å unngå utilsiktede tjenesteavbrudd.

5.11 Sluttoppgjør

For å unngå tvister om økonomi bør avtalen konkretisere hva som inngår i sluttoppgjøret, herunder utestående vederlag, lisensavgifter, kostnader til overgangsbistand, datatilbakelevering og eventuelle krediteringer eller refusjoner for forhåndsbetalte beløp.

Ofte kan det oppstå uenighet om hva som skal betales og når vederlaget skal betales. Av den grunn bør det blant annet presiseres hvordan sluttbetalingen skal beregnes og når den skal skje. Tidspunkt for sluttfakturering og betalingsforfall bør være klart, eksempelvis innen et definert antall dager etter endelig akseptert overlevering, med adskilt spesifikasjon av omtvistede og uomtvistede beløp samt regler for tilbakehold av det førstnevnte.

6.1 Innledning

Det bør foreligge en dokumentert exit-plan som er realistisk og testet. Planen må beskrive alle steg fra beslutning om exit til full gjennomføring, inkludert roller, ansvar og tidsfrister.

Det er også hensiktsmessig med en periodisk gjennomgang og oppdatering av planen for å sikre at den er tilpasset gjeldende risiko og avtalevilkår.

6.2 Risikovurderinger/kritikalitet

For å vite hva som bør gjøres og hvilke tiltak som bør på plass, er det sentralt å ha på plass vurderinger av risikonivået.

Forut for planen bør det foreligge en systematisk ROS-analyse (risiko og sårbarhet) for å identifisere trusler, sårbarheter og konsekvenser ved en exit. Vurder blant annet kritikaliteten til tjenestene: Hvilke funksjoner er forretningskritiske, og hvilke kan midlertidig settes på vent? Det enkleste er å bruke en metodikk som kombinerer sannsynlighet og konsekvens, og dokumentere akseptkriterier for risiko.

6.3 Identifisere alternative løsninger

Mulige alternative leverandører eller interne løsninger som kan overta tjenestene, bør kartlegges. Det kan også vurderes hvorvidt det er fornuftig med en multicloud-strategi eller bruk av åpne standarder for å redusere leverandørlås.

Kartlegg og dokumenter avhengigheter til proprietære moduler, tilpasninger, integrasjoner, lisensmekanismer og dataformater. For å redusere risiko bør det beskrives hvordan tilsvarende funksjonalitet sikres i ny løsning, og hvilke midlertidige tiltak som trengs for å unngå funksjonsavbrudd. Dersom det finnes uunngåelige proprietære avhengigheter, bør leverandøren forpliktes til konvertering eller tilgjengeliggjøring av nødvendig funksjonalitet i overgangsperioden på forutsigbare vilkår.

6.4 Informasjonssikkerhet

Informasjonen og tjeneste må sikres kontinuerlig beskyttelse, også i overgangsperioder. Det kan avtales om partene forholder seg til samme eller høyere/lavere sikkerhetsnivå i overgangsperioden

Tilgangsstyring bør på plass for å kontrollere tilgang for overgangsteam, prinsipp om minste privilegium, og raske avvikling av tilganger etter fullført migrasjon.

6.5 Migreringsplan

Migreringsplanen operasjonaliserer strategien til konkrete, tidfestede aktiviteter, kvalitetssikring og ansvarslinjer, og bør minst omfatte følgende:

• Overføringsløsninger
  Planen skal beskrive tekniske metoder for datauttrekk og overføring, herunder formater (fortrinnsvis åpne og dokumenterte), valideringsregler, datamodeller og metadata som gjør dataene anvendelige hos ny leverandør. Det bør fremgå hvordan integrasjoner håndteres, hvilke grensesnitt som benyttes, og hvordan konvertering, rensing og mapping utføres. Sikker overføring skal være kryptert og verifiserbar (for eksempel gjennom hash-summer og mottaksbekreftelser), med plan for inkrementelle uttrekk og endelig cutover.

• Hva som gjøres i migreringsperioden
  Migreringsperioden bør dekke parallell drift der det er nødvendig, datakvalitetskontroller, funksjonelle og tekniske tester, ytelsestester, feilretting og verifikasjon hos mottaker. Tjenestekontinuitet og SLA-nivåer i overgangsperioden må presiseres, med tydelige kriterier for når produksjon flyttes og hvordan eventuell tilbakerulling gjennomføres. Planen skal også adressere koordinering med tredjepartsleverandører og håndtering av lisensflyt.

• Bemanning
  Definer dedikerte roller og ansvar på tvers av partene, inkludert teknisk ledelse, sikkerhetsansvarlig, dataansvarlig, testleder og endringsleder. Kompetansekrav, tilgjengelighet og eskaleringspunkter bør beskrives, sammen med beslutningsmyndighet for å håndtere avvik og endringer uten forsinkende byråkrati. Kontinuitet i nøkkelressurser bør sikres, og det bør settes av kapasitet for kveld/helg ved kritiske milepæler.

• Testing av strategien
  Gjennomfør planlagte tester og øvelser, fra simple gjennomganger av prosess til tekniske uttak og fullskala prøvemigrering der det er mulig. Testkriterier, akseptterskler, suksessmål og læringspunkter skal dokumenteres, og planen oppdateres basert på resultatene. Det bør også testes for sikkerhet, herunder tilgangsstyring, data-integritet og hendelseshåndtering under migrering.

6.6 Håndtering av nedetid,

Nedetid må håndteres. Dette kan f.eks. innebære å inkludere maksimal tillatt nedetid under migrering eller avvikling i en Service Level Agreement (SLA) som regulerer slike spørsmål. Avtal kompensasjonsmekanismer ved brudd på SLA (f.eks. økonomisk kompensasjon eller ekstra support)

6.7 Håndtering av datatap

Datatap kan forebygges gjennom redundante uttak, validering og sikre gjenopprettingsmekanismer. Strategien bør omfatte krav til fullstendighet og integritet i uttrekk, kontrollsummer, referanse- og nøkkelkontroller, og verifikasjon av datalinjer. Backupløsninger og gjenopprettingstester må være dokumentert, med klar plan for når backuper tas, hvor de lagres, hvem som har tilgang og hvordan data gjenopprettes ved feil. Det bør også avtales dokumentasjonskrav og uavhengig bekreftelse for endelig sletting etter vellykket migrering.

6.8 Beredskapsplan

Beredskapsplanen skal sikre styring, transparens og rask håndtering av avvik under exit. Den bør beskrive styringsmodell med faste statusmøter, rapporteringsfrekvens, fremdriftsrapporter, risikologg med eiere og tiltak, endringskontroll, avvikshåndtering og eskalering. Videre bør den angi kommunikasjonslinjer internt og mot interessenter, klare roller i hendelseshåndtering, og kriterier for når ekstraordinære tiltak iverksettes.

Planen bør være koordinert med virksomhetens overordnede beredskaps- og kontinuitetsplaner, og inkludere tilgang til nødvendige ressurser og beslutningsmyndighet for å handle raskt.