Cloud Computing kontrakter

Vejledning om juridiske, kommercielle og tekniske forhold

i aftaler om Cloud Computing

Cloud Computing kontrakter

Vejledning om juridiske, kommercielle og tekniske forhold i aftaler om Cloud Computing

Udarbejdet af

Danske IT-advokater og DANSK IT

Cloud Computing kontrakter

Vejledning om juridiske, kommercielle og tekniske forhold i aftaler om Cloud Computing

Forfattere:

Xxxxx Xxx. Xxxxxxxxx, certificeret it-advokat, Xxxxxxx Xxx Xxxxxxxx, direktør, DANSK IT

Xxxxx Xxxxxxxx, it-direktør, Nilfisk-Advance

Xxxxx Xxxxxxxxx, digitaliseringschef, Danske Advokater

Layout:

DANSK IT

Kontakt:

Danske IT-advokater DANSK IT

Xxxxxxxxxxxxx 00 Xxxxxxxx 00x

DK 1620 København V DK 1260 København K

Tlf: x00 0000 0000 Tlf: x00 0000 0000

xxxxxxxx@xxxxxxxxxxxxxxx.xx xxx@xxx.xx

xxx.xxxxxxxxxxx.xx xxx.xxx.xx

Indhold

1 Indledning 5

2 Hvad er cloud computing? 7

3 Hvordan adskiller cloud sig fra andre it-ydelser? 9

4 Grundlæggende overvejelser 10

4.1 Fordele ved cloud computing 10

4.2 Ulemper ved Cloudløsninger 11

4.3 Kundens indledende selvevaluering af behov og risici 12

4.4 Detaljeret evaluering af Cloudløsningen 13

5 Typer af cloudkontrakter 15

5.1 Kan Kontrakten forhandles? 15

5.2 Er kontraktgrundlaget modent? 15

5.3 Hvad gør man, hvis Kontrakten ikke kan forhandles? 15

5.4 Internationale kontrakter 16

6 Cloudløsningens implementering 17

6.1 Omfanget af den nødvendige implementering 17

6.2 Hvordan håndteres implementeringsrisikoen 17

6.3 Særligt om ansvarsfordelingen 18

7 Afregningsmekanismer ved brug af Cloudløsningen 19

7.1 Licensmæssige aspekter 19

7.2 Rettigheder til Cloudløsningen efter ophør 20

7.3 Andre relevante forhold 20

8 Snitflader/grænseflader mellem Cloudløsningen og andre applikationer/software 21

8.1 Behovet for integrationer 21

8.2 Hvad bør man teknisk sikre sig? 22

9 Ændringer i ydelsen 23

10 Servicemål (SLA) 24

10.1 Betydningen af servicemål i Cloudløsninger 24

10.2 Måling 25

10.3 Konsekvenser ved manglende opfyldelse af servicemål 25

10.4 Anbefaling i forhold til servicemål 26

11 Erstatningsansvar og ansvarsbegrænsninger 27

	11.1 Baggrunden for Leverandørens ansvarsbegrænsninger	27
	11.2 Indholdet af ansvarsbegrænsninger	27
	11.3 Konsekvenser af ansvarsbegrænsninger	27
12	Håndtering af data og persondata	29
	12.1 Indledning	29
	12.2 Særligt om bogføringsdata	30
	12.3 Sektorspecifikke krav	31
	12.4 Opbevaring og behandling af data i udlandet	31
	12.4.1 Persondata	31
	12.4.2 Bogføringsdata	32
	12.4.3 Anbefaling	33
13	Sikkerhed	34
	13.1 Indledning	34
	13.2 Kundens egne undersøgelser af sikkerheden,
	herunder ved audit	34
	13.3 Virksomhedsspecifikke krav til sikkerhed	35
14	Exit	36
	14.1 Indledning	36
	14.2 Adgang til data efter ophør	36
15	Lock-in effekter ved brug af Cloudløsninger	37
16	Varighed af Kontrakter	39
	16.1 Uopsigelighedsperiode fra Leverandøren og Kundens
	side	39
	16.2 Ophævelsesmulighed ved misligholdelse	39
	16.3 Ændringer i vilkår, herunder prisændringer	40
	16.4 Konkurs og rekonstruktion	41
	16.5 Særligt om persondata ved ophør	41
17	Rettigheder til software/applikationer	43
	17.1 Ejendomsret til data	43
	17.2 Ejendomsret til software/Cloudløsningen	43

1 Indledning

Cloud computing har igennem længere tid været på dagsordenen hos de fleste virksomheder og it-leverandører i Danmark og i udlandet. Mange har dog stadig betænkeligheder ved cloud computing og har vanskeligt ved at overskue konsekvenserne ved at anvende løsninger baseret på cloud computing i deres virksomhed.

Cloud computing er ikke ny teknologi, men en anden måde at anvende eksiste- rende teknologi på, hvor brugeren (”Kunden”) på væsentlige punkter over- lader kontrollen til leverandøren af it-ydelsen (”Leverandøren”) og kommer ind i en standardiseret og færdigpakketeret verden af ”services”. Kundens formål med at overlade denne kontrol til Leverandøren er at opnå de fordele i form

af fleksibilitet, skalerbarhed, stabilitet og omkostningsbesparelser, som cloud computing i mange tilfælde vil give.

Formålet med vejledningen er at give Kunden en forholdsvis let og overskuelig vejledning i forhold til de spørgsmål, der bør stilles, og overvejelser, der bør gøres, før Kunden går ind i en løsning baseret på cloud computing (”Cloud- løsningen”).

Det særlige ved cloud computing er, at juridiske, kommercielle og tekniske for- hold vanskeligt kan skilles ad. Om en konkret Cloudløsning er det rette valg for Kunden, afhænger derfor ikke blot af en teknisk vurdering af Cloudløsningen, men også af juridiske, finansielle og strategiske overvejelser.

Vejledningen tager ikke stilling til, om cloud computing er en bedre eller rin- gere løsning for Kunden i forhold til alternativerne. Der kan i forhold til cloud computing peges på mange risici, men disse skal altid sammenholdes med fordelene. Endvidere vil mange af de risici, der redegøres for i vejledningen, genfindes i almindelig outsourcing og inden for traditionel it. Kunden bør derfor ikke fravælge en Cloudløsning alene på grundlag af identificerede risici, hvis disse risici også eksisterer i forhold til de alternative løsninger, som måtte findes. Vejledningen er med andre ord en checkliste og et ”inspirations- katalog” for Kunder, der ønsker at tage en Cloudløsning i brug.

Vejledningen retter sig først og fremmest til dem, som skal indgå og bruge kontrakten vedrørende Cloudløsningen (”Kontrakten”), og er skrevet ud fra et

ønske om, at den skal kunne læses og bruges af både jurister og ikke-jurister. Vejledningen kan ikke træde i stedet for konkret rådgivning, men det er hen- sigten, at vejledningen skal kunne give Xxxxxx et grundlag for selv at gøre sig sine overvejelser og fokusere på de rigtige spørgsmål.

Vejledningen er blevet til i et samarbejde mellem DANSK IT og Danske IT- advokater, og arbejdsgruppen har bestået af Certificeret IT-advokat fra Danske IT Advokater Xxxxx Xxx. Xxxxxxxxx (Plesner), Direktør i DANSK IT Xxx Xxxxxxxx, IT-direktør i Nilfisk-Advance Xxxxx Xxxxxxxx og Digitaliseringschef i Danske Advokater Xxxxx Xxxxxxxxx.

2 Hvad er cloud computing?

Der findes ikke en generelt anvendelig og alment accepteret definition af, hvad cloud computing er. De fleste anvender dog cloud computing som et begreb for it-løsninger, der leveres som tjenester i stedet for produkter. Cloudløsning- er er normalt kendetegnet ved, at

• De tilgås direkte via internettet

• Servicen betales efter forbrug

• Forbruget kan reguleres op og ned i Kontraktens løbetid, og

• Tjenesten leveres fra Leverandørens platform af puljede computer-

ressourcer

I hvilket omfang nævnte kendetegn gælder for den konkrete it-løsning, af- hænger dels af den tekniske løsning og dels af Kontrakten.

Normalt inddeles Cloudløsninger i tre kategorier:

• Software as a service (SaaS): Hvor Leverandøren stiller en tjeneste til rådighed i form af applikationer, som bliver hostet, drevet og vedlige- holdt af Leverandøren

• Platform as a service (PaaS): Hvor Leverandøren som en tjeneste stil- ler en webbaseret platform til rådighed som en tjeneste for Kunden. Platformen indeholder basissoftware, som gør det muligt for Kunden at lægge sine egne applikationer på platformen

• Infrastructure as a service (IaaS): Grundlæggende infrastruktur- tjenester stilles til rådighed med henblik på, at Kunden kan installere egen basissoftware og applikationer

Anvendelsen (”deployment”) af cloud ses i en række forskellige varianter i form af:

• Public cloud: Tjenstesterne leveres fra en offentlig tilgængelig infra- struktur (åbent netværk) med fælles standardiserede platform og infrastruktur

• Private cloud: Tjenesterne leveres fra en ikke-offentlig tilgængelig infrastruktur (lukket netværk) med platform og infrastruktur tilpasset den enkelte Kunde

• Community cloud: Tjenesterne leveres fra en infrastruktur, som er tilgængelig for en bestemt gruppe (community) med platform og infrastruktur tilpasset gruppen

Kombineres disse anvendelsesmodeller, tales der om hybridmodeller.

Normalt vil det være sådan, at jo højere oppe i ”stakken” man kom- mer, jo mindre kontrol vil man have med Cloudløsningen. Det vil sige, at en IaaS-løsning giver en større grad af kontrol og frihed end en SaaS-løsning, da Kunden i XxxX selv kan styre og kontrollere styresyste- mer og applikationer.

Cloud Services

Servere

Applikationer

Data

Middleware

Runtime

Operativsystem

Data

Middleware

Runtime

Kunden styrer

Packaged Software

Infrastructure

Applikationer

Kunden styrer

(as a service)

Platform

Applikationer

Kunden styrer

(as a service)

Software

Applikationer Data Runtime Middleware

Operativsystem Virtualisering Servere

Lager

Netværk

(as a service)

Servere

Data Runtime Middleware

Operativsystem Virtualisering Servere

Lager

Netværk

Operativsystem Virtualisering Servere

Lager

Netværk

Virtualisering

Servere

Lager

Netværk

Styret af leverandøren

3 Hvordan adskiller cloud sig fra andre it-ydelser?

I princippet er der ikke forskel mellem en Cloudløsning (SaaS) med en applika- tion solgt som software as a service og en løsning, hvor Xxxxxx selv køber ap- plikationen og driver denne på sin egen hardware og tilkøber vedligeholdelse og support.

For at Kunden kan komponere sin egen it-ydelse, skal Kunden således normalt:

• købe en softwarelicens

• implementere og tilpasse den købte software

• installere og drive applikationen,

• foretage vedligeholdelse og videreudvikling, og

• købe support hos leverandørerne

I en Cloudløsning leveres hele pakken som en færdig og forædlet tjenesteydel- se fra Leverandøren, og Xxxxxx har ikke som sådan indflydelse eller kontrol over produktionen.

For at Leverandøren kan levere denne færdigpakketerede tjeneste (service) til Kunden, er det nødvendigt i væsentligt omfang at acceptere de standard- løsninger og valg, som Leverandøren har gjort på vegne af alle de Kunder, der benytter Cloudløsningen.

Der vil i de fleste Cloudløsninger være mulighed for at foretage parameter- opsætninger og i et vist omfang foretage tilpasninger, som anvendes sammen med løsningen via en grænseflade (API). I det væsentlige må Kunden dog regne med, at det er en standardløsning, der købes, og at der derfor ikke kan foretages særlige tilpasninger i forhold til Kunden, hvilket gælder både i for- hold til selve løsningen, men også i forhold til servicemål og support, der stilles til rådighed.

Den afgørende forskel mellem cloud computing og traditionelle it- ydelser er således, at de ydelser, som Kunden normalt selv skal kombi- nere, leveres som en tjenesteydelse (service) i form af en samlet færdig pakke.

4 Grundlæggende overvejelser

4.1 Fordele ved cloud computing

De væsentligste fordele, der normalt kan opnås ved anvendelse af Cloud-

løsninger, er

• begrænsede eller ingen tekniske kapital- og opstartsomkostninger

(se dog om implementeringen af Cloudløsningen nedenfor)

• betaling i henhold til forbrug

• fleksibilitet i forhold til op- og nedskalering af computerressourcer

• mulighed for varierende aftalelængder

• mulighed for at operere med ”tynde klienter”

• mulighed for full-service løsninger og servicemål, hvor hele løsning-

ens performance er inkluderet

• mulighed for anvendelse af Leverandørens skalafordele (det vil sige anvendelse af Leverandørens serverkapacitet)

• løbende softwareopdateringer uden ekstraomkostninger

• andre sædvanlige outsourcingfordele (sikkerhed for oppetid, til- gængelighed, back up, nødberedskab mv.)

• miljømæssige fordele (CO2 reduktion ved at pulje it-løsninger i store

datacentre)

4.2 Ulemper ved cloudløsninger

Som modstykke til de nævnte fordele ved cloud computing skal Kunden sam- tidig forholde sig til de ulemper, som er ved anvendelse af cloud computing:

• risiko for at de lave opstartsomkostninger bliver ”spist” af løbende omkostninger ved køb af abonnement over en længere periode

• tab af kontrol i forhold til udvikling og softwareændringer

• tab af kontrol i forhold til drift

• ingen mulighed for at ”stå af toget” (der skal betales løbende

- Kunden er nødt til at have abonnementet)

• sårbarhed i forhold til at den samlede løsning skal leveres af én Leverandør (”lock-in”)

• trafikomkostninger i forhold til transport af data

• sårbarhed og afhængighed i forhold til at være online (have internet-

adgang)

• sikkerhedsrisici i forhold til uvedkommendes adgang til Cloud- løsningen

• vanskeligheder i forhold til integration med andre applikationer og

systemer

• begrænsede muligheder for tilpasninger

• risiko for manglende adgang til egne data ved ophør og overførsel af disse til Kunden selv eller ny Leverandør (Hvor sikker kan Kunden være på at kunne få rådighed over sine data, når Kontrakten ophø- rer), og

• regulatoriske/compliance risici i forhold til behandling af person- oplysninger i Cloudløsningen, se nærmere herom i afsnit 12 og 13 nedenfor.

4.3 Kundens indledende selvevaluering af behov og risici

For at Kunden kan forholde sig til det samlede billede af fordele og ulemper ved anvendelse af en Cloudløsning, bør Kunden i forhold til den Cloudløsning, som Kunden overvejer at tage i anvendelse, som minimum stille følgende spørgsmål:

Understøttelse af forretningen

• I hvor stor udstrækning er det fra Kundens side acceptabelt, at forret-

ningsprocesserne tilpasses softwaren og ikke omvendt?

Krav til serviceniveau (afsnit 10 og 11)

• Er det system, som Cloudløsningen erstatter (eller den nye funktion Cloudløsningen opfylder), kritisk for Kundens virksomhed (vil Kunden uafhængigt af Cloudløsningen rimeligvis kunne videreføre sin virk- somhed)?

• Harmonerer servicemål i forhold til oppetid og tilgængelighed med de servicemål, som Kunden anvender for de øvrige systemer/applikatio- ner?

IT-arkitektur og integration (afsnit 8 og 9)

• Hvordan passer Cloudløsningen ind i Kundens eksisterende system- landskab?

• Kan Cloudløsningen integreres med andre centrale systemer og applikationer hos Xxxxxx?

• Hvor vigtigt er det for Kunden, at Cloudløsningen kan tilpasses Kundens andre applikationer og systemer (er standard tilstrækkelig)?

Økonomisk kalkule (afsnit 6, 7 og 16)

• Hvad er økonomien på kort, mellemlang og lang sigt ved at tage en traditionel løsning i brug sammenlignet med omkostningerne ved køb af Cloudløsningen (vil det kunne svare sig at købe løsningen som

en Cloudløsning, eller bliver de umiddelbare fordele ”spist op” af de løbende omkostninger ved Cloudløsningen)?

• Er der væsentlige implementeringsomkostninger forbundet med at tage Cloudløsningen i anvendelse, herunder i forhold til integration med anden software og forandring af forretningsprocesser?

Sikkerhed og compliance (afsnit 12 og 13)

• Er Leverandørens sikkerhedsniveau tilfredsstillende (er det tilfreds- stillende både i forhold til adgangskontrol, databehandling samt nød- og katastrofeberedskab)?

• I hvilke lande skal data opbevares eller tilgås fra?

• Har Kunden behov for at kunne dokumentere opfyldelse af særlige re-

gulatoriske krav eller compliancevilkår i forhold til behandling af data?

Exit (afsnit 14-17)

• Hvordan kommer Kunden ud af Cloudløsningen?

• Er der bindinger, der skaber lock-in?

• Har Kunden behov for særlige rettigheder til software efter ophør af

Kontrakten?

4.4 Detaljeret evaluering af Cloudløsningen

Når Xxxxxx har foretaget den indledende selvevaluering af egne behov og en overordnet risikovurdering, bør Kunden tage stilling til, om Xxxxxx ønsker at gå ind i en dybere undersøgelse af Cloudløsningens fordele og ulemper.

Det afgørende er, at Kunden i sin tilgang får stillet de rigtige spørgs- mål i rette tid således, at det undgås, at der enten ikke investeres unødig tid og ressourcer i undersøgelse af en Cloudløsning, som allige- vel ikke vil opfylde Kundens behov, eller at Kunden først for sent bliver opmærksom på Kundens egne behov og krav til risici, ikke er afstemt med det, som Cloudløsningen kan tilbyde.

I den følgende del af vejledningen vil de enkelte elementer i Cloudløsningen blive gennemgået i forhold til de mere deltaljerede overvejelser, som man som Kunde bør gøre sig, hvis man vil tage en Cloudløsning i anvendelse.

5 Typer af cloudkontrakter

5.1 Kan Kontrakten forhandles?

En stor del af de Cloudløsninger, som kan købes i dag, leveres på grundlag af standardvilkår, som ikke eller kun vanskeligt kan forhandles med Leveran- døren. Baggrunden herfor er, at Leverandørens forretningsmodel er baseret på salg af rene standardprodukter, og dels at produktet grundlæggende er nødt til at være ens for alle Kunder, da Leverandøren ellers ikke vil opnå de stordrifts- fordele, der er forbundet med at levere it-løsningen som en Cloudløsning. Der findes dog også Cloudløsninger, som kan købes efter tilpassede vilkår, og hvis den volumen, som Kunden vil købe, er tilstrækkelig stor, vil visse af vilkårene også kunne forhandles.

Det første, Kunden derfor bør undersøge, er, om Kontrakten kan gøres til genstand for forhandling, eller om Xxxxxx er nødt til at tage Kon- trakten, som den er.

5.2 Er kontraktgrundlaget modent?

Ved vurdering af Kontrakten er det samtidig vigtigt, at Kunden undersøger, om kontraktgrundlaget er tilstrækkeligt gennemarbejdet. Der er i markedet i dag en lang række Leverandører, som enten er nye i markedet, eller er ved at konvertere fra en traditionel it-leverancemodel til en cloudbaseret leverance- model. Er der tale om sådanne umodne Leverandører, skal Kunden dels være opmærksom på, om Leverandøren rent faktisk kan levere en tilfredsstillende ydelse, hvis procedurerne ikke er beskrevet tilstrækkeligt præcist, og dels skal Kunden sikre sig, at der forhandles et konsistent og tilfredsstillende sæt vilkår.

5.3 Hvad gør man, hvis Kontrakten ikke kan forhandles

Hvis det må konstateres, at Kontrakten ikke kan forhandles, består Kundens opgave i at foretage en vurdering af, om det tilbudte produkt udover at leve op til Kundens tekniske krav også lever op til de krav, som Kunden har stillet i

forhold til risici, og til de regulatoriske krav til Kontraktens indhold. En sådan vurdering kan enten føre til, at Kunden skal afstå fra at indgå Kontrakten, fordi risikoen er for stor/manglende compliance, eller at risikoen er håndterbar sammenholdt med investeringens størrelse og betydningen af de involverede data.

5.4 Internationale kontrakter

En stor del af Leverandørerne af Cloudløsninger vil ikke være hjemmehørende i Danmark, og Cloudløsninger er netop kendetegnet ved at have et interna- tionalt salgspotentiale. Det gør samtidig, at Kontrakten ofte er undergivet udenlandsk ret, og at udenlandske domstole eller voldgifter er indsat som de retsinstanser, der skal afgøre eventuelle tvister.

Som i alle andre kontraktforhold bør Kunden også have øje for, om en reel håndhævelse af Kontrakten er (økonomisk) mulig, herunder i forhold til kon- traktværdien af Kontrakten.

6 Cloudløsningens implementering

6.1 Omfanget af den nødvendige implementering

De fleste Kunder (om ikke alle) er opmærksomme på, at traditionelle it- løsninger skal implementeres for at kunne anvendes i virksomheden. Det samme gælder Cloudløsninger, og det er derfor vigtigt, at Kunden får analy- seret, hvilket omfang Cloudløsningens implementering vil have i det konkrete tilfælde.

Indledningsvist er det væsentligt at få afdækket, om Cloudløsningen under- støtter de processer, som Kunden ønsker løst, ved at tage Cloudløsningen i anvendelse. Hvis der er et ”gap”, mellem det Cloudløsningen kan tilbyde og de funktioner og processer, som Kunden har behov for at få dækket, er det første spørgsmål, om det i det hele taget er muligt at udvikle særlig funktionalitet, der kan dække et sådant gap, herunder om denne funktionalitet kan etableres i regi af Leverandøren.

Kunden bør også i den forbindelse, uanset om Cloudløsningen opfylder samt- lige af Kundens behov, undersøge fleksibiliteten i Cloudløsningen i forhold til at kunne indgå i Kundens udviklingsplaner, hvis behovene hos Kunden ændrer sig.

Når behovsopfyldelsen er afklaret, bør de samlede omkostninger ved imple- mentering, herunder i forhold til parameteropsætning, træning og integration med Kundens andre it-løsninger vurderes med henblik på at vurdere den sam- lede økonomi i anskaffelsen.

6.2 Hvordan håndteres implementeringsrisikoen

En særlig problemstilling er, hvem der skal påtage sig implementeringsrisikoen. I traditionelle it-projekter eller udviklingsprojekter vil Leverandøren normalt have implementeringsrisikoen, således at Leverandøren først anses for at have leveret, når det tilpassede standardsystem er accepteret af Kunden.

De fleste cloudkontrakter indeholder ikke en sådan fordeling af risikoen. Om- vendt vil Cloudløsningen i mange tilfælde kunne opsiges med meget kort var-

sel, hvilket giver Xxxxxx den fornødne frihed til at komme ud af Kontrakten, hvis implementeringen ikke kan gennemføres til Kundens tilfredsstillelse.

Kunden skal også ved udarbejdelsen af sin business case være opmærksom på, at nogle Leverandører - ligesom ved licenskøb - kræver, at adgang til Cloud- løsningen er erhvervet allerede for tidspunktet for påbegyndelse af implemen- teringen. Kunden kommer dermed til at betale for Cloudløsningen, selvom den ikke er i produktion hos Kunden.

Hvis Kontrakten er genstand for forhandling, bør Kunden søge enten at opnå en aftale om betaling efter forbrug (eksempelvis betaling for testbrugere) eller at udskyde tidspunktet for betaling for anvendelse af Cloudløsningen, indtil implementeringen er gennemført, og i øvrigt sikre sig, at Kunden ikke er bundet af Kontrakten, hvis implementerin- gen ikke lykkedes.

6.3 Særligt om ansvarsfordelingen

Hvis implementering gennemføres af en anden end Leverandøren af selve Cloudløsningen, er det ligesom i traditionelle it-projekter vigtigt at forholde sig til implementeringsrisikoen.

Uanset at selve Kontrakten for Cloudløsningen ikke kan forhandles, vil imple- menteringsaftalen normalt både kunne og skulle forhandles, og Xxxxxx bør her sikre sig, at der er en rimelig risikofordeling mellem Kunden og den part, der påtager sig implementering.

7 Afregningsmekanismer ved brug af Cloudløsningen

7.1 Licensmæssige aspekter

Det særlige ved cloud computing er, at der er tale om en tjeneste (service), hvor Kunden får adgang til en it-løsning, som drives og vedligeholdes af Leve- randøren. Betaling for brug kan derfor bedst sammenlignes med et abonne- ment (”subscription”), og er en løbende betaling for adgang til Cloudløsningen.

Da det er selve adgangen, man betaler for, er der teknisk set ikke tale om en licensaftale. Selve adgangen til at bruge den it-ydelse, som leveres, som en del af Cloudløsningen, indebærer imidlertid en form for licens for Kunden. Grund- læggende kan Cloudløsningen afregnes efter (i) antallet af brugere, (ii) forbrug,

(iii) kapacitet, (iv) transaktioner, (v) tilgængelig funktionalitet eller en kombina- tion af disse. Kunden bør forstå afregningsmodellen og prismekanismerne for Cloudløsningen. Typisk har Leverandørerne hver deres unikke måde at afregne efter, og Kunden bør derfor sikre sig, at det er klart, hvad Leverandøren forstår ved forbrug, brugere eller lignende under Kontrakten.

Uanset om der afregnes efter antal brugere, forbrug eller en kom- bination heraf, skal Kunden sikre sig, at der vil være adgang for alle relevante brugere hos Kunden. Det gælder både ansatte, men også indlejede konsulenter og tredjemandsleverandører (leverandører som leverer andre it-ydelser til Kunden).

Er der tale om brugerbaseret afregning, bør det ligesom ved licensaftaler un- dersøges, om afregning sker i forhold til samtidige eller unikke brugere. Kun- den bør også sikre sig, at afregninger er overskuelige og kan valideres, hvilket kan efterprøves ved at få et eksempel på afregning. Det anbefales, at Kunden får indbygget spærremekanismer eller alarmer i forhold til forbrugsbaseret afregning med henblik på at undgå negative overraskelser.

7.2 Rettigheder til Cloudløsningen efter ophør

I modsætning til traditionelle it-løsninger, hvor Kunden køber en evigtvarende licens til software, har Kunden som udgangspunkt ingen rettigheder til brug af software, når Kontrakten vedrørende Cloudløsningen ophører. Dette er som regel ikke et problem, men Xxxxxx skal gennemtænke, om der er behov for at beholde adgang til systemet efter ophør af ordinær brug med henblik på opbevaring og tilgang til arkivdata. Endvidere kan der være behov for adgang til løsningen, indtil en migrering til en anden løsning er endeligt gennemført, hvilket også bør sikres via Kontrakten.

7.3 Andre relevante forhold

I tillæg til betaling for adgang til Cloudløsningen kan der være et behov for tilkøb af supplerende produkter i form af support og lignende, som ikke nød- vendigvis indgår i selve Cloudløsningen.

Kunden bør sikre sig, at der kun betales for sådanne tilkøbte ekstra- produkter, så længe selve hovedydelsen, nemlig adgang til Cloud- løsningen, er tilgængelig.

8 Snitflader/grænseflader mellem Cloud- løsningen og andre applikationer/software

8.1 Behovet for integrationer

Et væsentligt aspekt ved Cloudløsningen er, at de data, der behandles, i mange tilfælde skal kunne bruges i andre applikationer eller sammenhænge. Behovet for integrationer er helt afhængig af, hvilken Cloudløsning der er tale om.

Er der tale om en IaaS-løsning, vil Kunden i langt højere grad selv kunne fore- stå integrationer, hvorimod integrationer fra en SaaS-løsning vil skulle basere sig på den pågældende Cloudløsning. Spørgsmålet om integrationer er vanske- ligt, da det ikke blot kan afklares ud fra et øjebliksbillede (det vil sige, hvad har Kunden brug for på indkøbstidspunktet). Kunden bør også tænke langsigtet

i forhold til at sikre, at behovet for eventuelle fremtidige integrationer kan

opfyldes.

Derfor bør Kunden som minimum sikre sig, at Leverandøren tilbyder standard API’er til integration med de af Kundens øvrige applikationer, der skal eller po- tentielt kan tænkes at skulle integreres til. Hvis det ikke er tilfældet, og hvis der er mulighed for at forhandle Kontrakten, bør det indskrives, at Leverandøren er forpligtet til at udvikle de manglende API’er og/eller sørge for, at løsningen giver mulighed for ved brug af standard interfaces at gennemføre integration med andre applikationer, herunder andre Cloudløsninger. Alternativt bør Kunden sikre sig, at der i markedet findes 3. parts integrationsprodukter, der giver mulighed for standardintegrationer mellem den påtænkte SaaS løsning og andre udbredte Cloudløsninger i markedet og de af Kundens applikationer, som Cloudløsningen kan tænkes at skulle integreres til.

8.2 Hvad bør man teknisk sikre sig?

Typisk vil Kunden have behov for at undersøgende følgende spørgsmål:

• Er der i Cloudløsningen browserunderstøttelse af de browsere, som Kunden anvender, og vil anvende i fremtiden?

• Er der begrænsninger i forhold til det hardware, som Cloudløsningen kan tilgås fra?

• Er der med Cloudløsningen integration til sædvanlige tredjeparts-

produkter såsom NemID?

• Kræver Cloudløsningen anvendelse af applikationer på terminalen (device), som anvendes af Kundens brugere til at tilgå Cloud- løsningen?

• Kan der etableres AD-integration med single sign on (enten direkte

eller via tredjepartsprodukter)?

• Er der ressourcekrav i forhold til de terminaler (devices), som benyt- tes til at tilgå Cloudløsningen?

• Vil der kunne skabes den fornødne hastighed på integrationer til an- dre systemer (skal de fornys for at skabe tilstrækkelig hastighed)?

• Xxxxxx former for API’er til udvikling af kundespecifikke løsninger stil- les til rådighed ?

• Hvilke standard integrationsmuligheder stilles til rådighed?

Da det, som Kunden typisk køber, er adgangen til en standardløsning, er spørgsmålet om ændringer væsentligt. Grundlæggende kan spørgsmålet deles op i to:

1. I hvilket omfang kan jeg som kunde kræve ændringer, og

2. I hvilket omfang skal jeg som kunde tåle ændringer.

Mange Kontrakter med Leverandører er meget åbne på dette punkt, og giver Leverandøren adgang til at foretage ændringer med kort var- sel eller af og til uden varsel. Kunden bør derfor nøje overveje, i hvilket omfang ændringer i Cloudløsningen ville kunne få indflydelse på andre af Kundens applikationer og systemer, og om selve Cloudløsningen

er så vigtig for Kunden, at Kunden ligefrem skal kunne modsætte sig

ændringer i Cloudløsningen.

I forhold til det første spørgsmål, om Kunden kan kræve ændringer, kan et sådant behov være foranlediget af, at Kunden får tilkøbt nye applikationer eller systemer, og/eller at opgradering af Cloudløsning er nødvendig for at kunne drive Kundens andre applikationer. Eksempelvis kan det i en IaaS eller PaaS Cloudløsning være en forudsætning, at basissoftware i Cloudløsningen er op- graderet til en nyere version, for at Kundens applikationer kan opgraderes til en højere version. Det kan derfor være tilsvarende vigtigt at sikre sig, at Kun- den kan kræve ændringer i Cloudløsningen.

I det omfang der ikke efter Kontrakten kan kræves ændringer, eller Kunden ikke kan forhandle sig frem til en sådan mulighed, bør Kunden vurdere Cloud- løsningen ud fra, om den fremstår tilstrækkelig robust, og om Leverandøren kan forventes at ville bevæge Cloudløsningen i den retning, som Kunden har behov for. Principielt ville spørgsmålet om ændringer ikke være af væsentlig betydning, hvis der ikke var ”lock-in” eller exitbarrierer, da Kunden i tilfælde af manglende imødekommelse af Kundens behov ville kunne skifte til en an-

den Leverandør. Da der imidlertid netop ofte er sådanne ”lock-in” effekter og vanskeligheder ved en exit, er dette forhold stadig af væsentlig betydning at få afdækket for Kunden.

10.1 Betydningen af servicemål i Cloudløsninger

Servicemål spiller en central rolle i forhold til Cloudløsningen, da det netop er adgangen til løsningen, som er selve produktet. Man kan gå så vidt som at sige, at produktet er lig med servicemålet i den forstand, at tjenesten (i form af adgangen til service) ikke er bedre end de servicemål, der leveres. Kunden bør derfor fokusere på, hvilke servicemål, der garanteres eller stilles i udsigt

fra Leverandørens side særligt i forhold til tilgængelighed og svartid, herunder i forhold til geografiske forhold.

Udover oppetid, tilgængelighed og svartid for selve Cloudløsningen er det også relevant at undersøge servicemål for blandt andet support og vedligeholdelse. Hvor hurtigt tilbyder Leverandøren at igangsætte udbedring af fejl, lover Leverandøren fejlrettelse eller workaround inden for en bestemt tidsperiode og lover Leverandøren at svare på supporthenvendelser indenfor en angivet tidsfrist?

Ikke alle Cloudløsninger tilbydes med garanterede servicemål, og i de fleste til- fælde vil de juridiske konsekvenser fastlagt i Kontrakten i forhold til manglende overholdelse af servicemål være begrænsede. Endvidere vil servicemål ofte kunne ændres af Leverandøren i Kontraktens løbetid, se afsnit 9 og 16.3 om ændringer i henholdsvis ydelsen og Kontrakten. Kunden er derfor nødsaget til

i realiteten selv at påtage sig risikoen, medmindre der i markedet tilbydes mu- lighed for at købe ydelsen gennem en forhandler, der er villig til at garantere servicemål med tilhørende juridiske konsekvenser, som er tilfredsstillende for Kunden.

Hvis Kunden ikke kan afdække den juridiske risiko for Cloudløsningens tilgæn- gelighed og svartid i Kontrakten, er Kunden henvist til at undersøge Leveran- dørens historiske performance, afprøve Cloudløsningen ved pilotprojekter eller ikke-kritiske applikationer eller begrænse anvendelse af Cloudløsningen til sådanne, sikre at der kan migreres relativt hurtigt og risikofrit til en alterna- tiv løsning og lignende tiltag.

10.2 Måling

Det er ligeledes vigtigt at være opmærksom på, hvorledes oppetid, tilgænge- lighed og svartid måles fra Leverandørens side, og hvordan dette kan verifice- res:

• Måler Leverandøren forskellige steder i verden, eller måles der kun ud af et konkret datacenter/land?

• Hvilket udstyr anvender Leverandøren til at måle med, herunder en- hed (device), browser, version og anvendt tredjepartssoftware?

Der kan være forskelle på, hvad der opleves i Leverandørens ende, og hvad Kunden oplever, da ydelsen typisk aftages via internettet, hvor kapacitet, kvali- tet og forsinkelser påvirker oplevelsen.

Endvidere er mange servicemål betingede og undtager særlige situationer fra måleperioden eller opererer med lange måleperioder, som udvander værdien af servicemålet. Et eksempel herpå er, at andre kunders adfærd, eksempelvis ved afvikling af store uannoncerede jobs, påvirker oplevelsen kortvarigt, uden at det kan ses i de offentliggjorte målinger af servicemål.

10.3 Konsekvenser ved manglende opfyldelse af servicemål

Ofte vil Leverandører af Cloudløsninger lade manglende opfyldelse af service- målene udløse en form for reduktion i vederlaget, hvilket kan sammenlignes med enten en bod eller et forholdsmæssigt afslag i ydelsen. Det er også ofte sådan, at denne reduktion i vederlaget angives at være den eneste sanktion og konsekvens af manglende opfyldelse af servicemål. Kunden skal derfor være meget opmærksom på, hvad konsekvenserne af i øvrigt tilfredsstillede servicemål er i Kontrakten, og om Kunden kan leve med en begrænset beskyt- telse ved ikke at have adgang til at kræve erstatning for manglende adgang til Cloudløsningen. Kunden bør også vurdere, om det vil være praktisk muligt at håndhæve sanktionen - det kan eksempelvis være problematisk, hvis Kontrak- ten er undergivet domstole i udlandet.

I det omfang Kontrakten ikke er genstand for forhandling, er Xxxxxx overladt til at foretage en risikovurdering af Leverandøren, herunder baseret på Leve- randørens historik, jf. ovenfor.

10.4 Anbefaling i forhold til servicemål

Undersøg nøje hvilke servicemål (om nogen) der garanteres for Cloud- løsningen i forhold til oppetid, tilgængelighed og svartid, og hvordan performance måles. Bed om oplysninger om Leverandørens historiske performance. Undersøg også hvilke servicemål der er for support og vedligeholdelse, og i øvrigt hvilke sanktioner der er ved Leverandørens manglende overholdelse af servicemål. Hvis de juridiske konsekven- ser er begrænsede og ikke kan forhandles, må Kunden forlade sig på Leverandørens historik, afprøve Cloudløsningen indtil Kunden føler sig tilstrækkelig komfortabel med den og i øvrigt sikre sig, at en exit kan foretages sikkert, hurtigt og effektivt uden væsentlige omkostninger.

11 Erstatningsansvar og ansvarsbegrænsninger

11.1 Baggrunden for Leverandørens ansvarsbegrænsninger

De fleste Cloudløsninger er i deres udgangspunkt tænkt som masseproduk- ter, og Leverandørerne har derfor i deres standardvilkår i Kontrakten indføjet ansvarsbegrænsninger, som i meget væsentligt grad begrænser Leverandørens ansvar for ydelsen. Leverandørernes baggrund for at gøre dette er typisk be- grundet i, at der i prisen for tjenesterne ikke er indregnet en risikopræmie for Kundernes tab ved brug af tjenesterne, og at det, som Kunderne køber, ikke

er en ”forsikring” mod skade. Problemstillingen svarer til den, som kendes fra outsourcing- og udviklings/implementeringskontrakter, men for Cloudløsnin- ger gør der sig det særlige gældende, at Leverandørerne i endnu højere grad har begrænset muligheden for at kræve erstatning.

11.2 Indholdet af ansvarsbegrænsninger

Ansvarsbegrænsningerne er forskellige for de enkelte Leverandører, men har typisk følgende indhold:

• Kunden kan ikke kræve erstatning for indirekte tab, som normalt defi- neres som driftstab, tabt fortjeneste, tab af goodwill og lignende

• Det samlede erstatningsansvar er beløbsmaksimeret svarende til den faktiske betaling eller betaling for en nærmere bestemt periode (ek- sempelvis 12 måneders vederlag)

Typisk vil det være anført, at begrænsningerne ikke gælder ved grov uagtsom- hed eller forsæt fra Leverandørens side

11.3 Konsekvensen af ansvarsbegrænsninger

Ansvarsbegrænsningerne er typisk enten meget vanskelige at forhandle eller ikke mulige at ændre. Juridisk set står Xxxxxx derfor typisk i den situation, at Kunden afgiver kontrol, men at det juridiske ansvar (erstatningsansvar) ikke følger med i fuldt omfang, og Kunden må derfor beslutte, om Cloudløsningen er så robust, at Kunden kan acceptere den juridiske risiko, der ligger i anven-

delse af Cloudløsningen.

En god måde at anskue situationen på er at gennemtænke et scenarie, hvor Xxxxxx selv har kontrol over de ydelser, som Cloudløsningen leverer, sammen- holdt med en situation, hvor Leverandøren har kontrollen. I de fleste tilfælde vil Kunden have den samme forsikringsdækning (eller mangel på samme) i forhold til dækning af driftstab mv. Den afgørende forskel bliver derfor, om Xxxxxx, hvis Xxxxxx selv var i kontrol, kunne have afværget de begivenheder, som afstedkommer tabet, eller eventuelt kunne have gjort det hurtigere og mere effektivt end Leverandøren. Dette skal så sammenholdes med omkost- ningerne ved et sådant beredskab. Det afgørende bliver således, om Xxxxxxx- døren kan bevise, at Leverandørens beredskab er lige så godt, som det Xxxxxx selv etablerer, hvis Xxxxxx selv havde drevet Cloudløsningen.

I kontrakter vedrørende Cloudløsninger ses typisk også bestemmelser om, at betaling af bod for manglende overholdelse af servicemål er den eneste juridiske sanktion, og at der derfor slet ikke kan gøres et erstatningsansvar gældende, udover de aftalte bodsbeløb.

Hvis Xxxxxx som følge af ansvarsbegrænsninger er overladt den juridiske risiko, er Kunden henvist til at undersøge Leverandørens historiske perfor- mance, afprøve Cloudløsningen ved pilotprojekter eller ikke-kritiske applika- tioner, begrænse anvendelse af Cloudløsningen til ikke-kritiske applikationer, sikre at der kan migreres relativt hurtigt og risikofrit til en alternativ løsning og lignende tiltag.

Kunden bør gennemgå og afdække ansvarsbegrænsningerne og fore- tage en risikovurdering, som dels går på, hvordan Kunden ville være stillet, hvis Xxxxxx selv havde drevet Cloudløsningen, sammenholdt med hvis denne drives af Leverandøren. Kunden bør derefter vurdere, om Leverandørens beredskab er passende i forhold til den risiko, Kun- den ønsker at løbe, og om prisen for ydelsen for Kunden afspejler det forhold, at Kunden ikke får dækning for de risici, som Kunden løber ved at tage Cloudløsningen i anvendelse.

12 Håndtering af data og persondata

12.1 Indledning

Et af de centrale spørgsmål ved anvendelse af Cloudløsninger har historisk været og er stadig spørgsmålet om behandling af data, herunder ikke mindst persondata.

Problemstillingerne vedrørende behandling af data adskiller sig ikke væsentligt fra de problemstillinger, som kendes fra behandling af data i et outsourcing- forhold. Der er derfor ikke som udgangspunkt persondataretlige grunde til at fravælge cloud computing til fordel for anden form for outsourcing. I person- datalovens forstand er Kunden typisk dataansvarlig, og Leverandøren bliver dermed databehandler for Kunden som dataansvarlig. Behandler Kunden i forvejen data for andre (og er dermed selv databehandler), bliver Leverandø- ren underdatabehandler for Kunden.

Anvendelse af databehandlere stiller en række krav til Kunden, som blandt an- det har pligt til at sikre sig, at det i Kontrakten anføres, at Leverandøren alene handler efter instruks fra den dataansvarlige, og at der træffes de fornødne tekniske og organisatoriske sikkerhedsforanstaltninger mod at oplysninger hændeligt eller ulovligt tilintetgøres, fortabes eller forringes, samt mod, at de kommer til uvedkommendes kendskab, misbrug eller i øvrigt behandles i strid med persondataloven (persondatalovens § 41, stk. 3). Der henvises i øvrigt til afsnit 13 nedenfor vedrørende sikkerhed.

Persondatalovens § 41, stk. 3:

”Den dataansvarlige skal træffe de fornødne tekniske og organisa- toriske sikkerhedsforanstaltninger mod, at oplysninger hændeligt eller ulovligt tilintetgøres, fortabes eller forringes, samt mod, at de kommer til uvedkommendes kendskab, misbruges eller i øvrigt be- handles i strid med loven. Tilsvarende gælder for databehandlere.”

Er der tale om ”følsomme” oplysninger som defineret i lovens § 7 (oplysninger om racemæssig eller etnisk baggrund, politisk, religiøs eller filosofisk over-

bevisning, fagforeningsmæssige tilhørsforhold og oplysninger om helbreds- mæssige og seksuelle forhold), kan der være behov for iagttagelse af særlige sikkerhedsforanstaltninger.

Anvendes Cloudløsningen til at behandle persondata, skal Kunden vurdere, om Kontrakten indeholder en forpligtelse for Leverandøren til at etablere og opretholde de fornødne tekniske og organisatoriske sik- kerhedsforanstaltninger. Kunden må således vurdere, om sikkerheden i løsningen er tilstrækkelig god og ligger inden for rammerne af den risikovurdering og risikohåndtering, som Xxxxxx selv anlægger ved sin egen behandling af persondata.

Er Kunden selv databehandler for en anden dataansvarlig, skal Kunden sikre, at de krav, som den dataansvarlige har stillet over for Kunden, også opfyldes ved Cloudløsningen. Der kan også være pligt til at ind- hente tilladelse fra Kunden til at bruge en underdatabehandler.

12.2 Særligt om bogføringsdata

Mange SaaS-løsninger indeholder funktioner, der opbevarer og behandler bogføringsdata. Bogføringsdata er omfattet af bogføringsloven, som stiller en række generelle og specifikke krav til bogføringen, således skal bogføring- en blandt andet tilrettelægges og udføres således, at regnskabsmaterialet ikke ødelægges, bortskaffes eller forvanskes, ligesom det skal sikres mod fejl og misbrug (bogføringslovens § 6). På samme måde som med behandling af persondata bør Kunden undersøge, om der er truffet de fornødne foranstalt-

ninger, som opfylder de generelle specifikke krav, der er i bogføringsloven, hvis der i Cloudløsningen behandles bogføringsdata. Se i øvrigt afsnit 12.4.2 om opbevaring af bogføringsmateriale i udlandet

12.3 Sektorspecifikke krav

Mange brancher er underlagt sektorspecifikke krav i forhold til behandling af data. Det gælder eksempelvis den finansielle sektor, som er forpligtet til at sikre, at data behandles efter vedtagne politikker og retningslinjer udarbejdet i henhold til lov om finansiel virksomhed. Tilsvarende gælder sundhedsloven for institutioner, virksomheder og personer, som agerer inden for sundheds- væsenet, hvor Kunden skal sikre sig, at sådanne sektorspecifikke krav til data- behandling også opfyldes.

12.4 Opbevaring og behandling af data i udlandet

12.4.1 Persondata

En væsentlig del af rationalet i anvendelse af Cloudløsninger er, at der etable- res store datacentre, som benyttes til opbevaring af data for Kunderne under de enkelte Cloudløsninger. I Cloudløsninger baseret på public cloud vil det ofte være sådan, at data opbevares forskellige steder.

I forhold til behandling af persondata er det sådan, at behandling kan ske in- den for EU/EØS, uden at dette kræver iagttagelse af særlige forhold. Det skyl- des, at der via EU er vedtaget fælles regler for behandling af persondata, som sikrer en fælles minimumstandard for behandling af personoplysninger. Over- føres persondata til lande uden for EU (eksempelvis USA eller Indien), er der - medmindre landet er godkendt som ”sikkert tredjeland” - tale om overførsel til ”usikre tredjelande”. Overførsel til usikre tredjelande kræver efter persondata- lovens regler, at der tilvejebringes et særligt grundlag (eksempelvis samtykke eller aftaleopfyldelse), eller at der ydes tilstrækkelige garantier til beskyttelse af de registreres rettigheder, hvilket bl.a. kan sikres ved standardkontrakter baseret på de såkaldte EU model clauses eller ved brug af virksomhedens egne bindende virksomhedsregler (”Binding Corporate Rules”). I visse tilfælde skal der også indhentes tilladelse til en tredjelandsoverførsel hos Datatilsynet.

Særligt i forhold til USA er det vigtigt at holde den særlige ”Safe Harbour” ord- ning for øje, hvorved enkelte selskaber i USA - under visse omstændigheder

- kan betragtes som ”sikre” at overføre data til, hvorfor behovet for et særskilt hjemmelsgrundlag falder bort. Kunden bør undersøge direkte i Safe Harbour registret, om Leverandøren er certificeret til at modtage de pågældende per- sonoplysninger til det formål at levere tjenester til virksomheder som Kunden.

Persondataloven kræver, at Kunden ved, hvor persondata behandles. Dette kan give udfordringer i Cloudløsninger, hvor Leverandøren har mange data- centre spredt på flere forskellige geografiske lokationer og benytter dem efter eget valg til at opbevare Kundens persondata. En måde at løse problemstillin- gen på er derfor at bede Leverandøren om at give en lokationsgaranti (”loca- tion guarantee”). Fjernadgang til en database sidestilles med en overladelse/ videregivelse af oplysningerne og adgang for personer i eksempelvis et ser- vicecenter i Indien vil derfor kræve et særligt grundlag, hvis persondata kan tilgås fra servicecentret. Hvis standardkontrakterne anvendes uden ændringer, kræves der ikke tilladelse fra Datatilsynet. Foretages der imidlertid selv mindre ændringer i standardkontraktens bestemmelser, vil en sådan tilladelse skulle indhentes, hvilket vil indebære en væsentlig forsinkelse.

12.4.2 Bogføringsdata

For så vidt angår bogføringsdata, gælder der det særlige, at bogføringsdata skal behandles i Danmark, medmindre der er indhentet tilladelse til behand- ling uden for Danmark (bogføringslovens § 12). Det vil normalt være muligt

at opnås en sådan tilladelse, men det vil give anledning til problemer, hvis det ikke i ansøgningen kan specificeres, hvor data vil skulle opbevares. Det for- ventes, at bogføringsloven vil blive ændret i den nærmeste fremtid, således at elektronisk opbevaring kan ske i udlandet uden særskilt tilladelse, når visse krav er opfyldt.

12.4.3 Anbefaling

Kunden - og/eller dennes rådgiver - bør undersøge, hvor data fysisk opbevares og behandles. Hvis det drejer sig om persondata og be- handlingen sker uden for EU/EØS, skal Kunden sikre sig, at der i det fornødne grundlag hertil (f.eks. Safe harbour, Model Clauses/Binding Corporate Rules). Er der tale om bogføringsdata, vil det være nødven- digt at indhente formel tilladelse fra Erhvervsstyrelsen til behandling uden for Danmark. Kunden bør i alle henseender søge at få afdækket konkret, i hvilke datacentre behandlingen sker. Ligeledes vil der efter omstændighederne være behov for at indhente tilladelse til en overfør- sel af persondata fra Datatilsynet.

13 Sikkerhed

13.1 Indledning

En afgørende og væsentlig parametre i forhold til anvendelse af Cloudløs- ningen er, om Leverandørens sikkerhedsforanstaltninger og beredskab er fornødent, passende og tilstrækkeligt, herunder i forhold til Kundens egne risikovurderinger og de krav der stilles i henhold til gældende lovgivning. Le- verandørerne vil typisk kunne fremlægge revisionserklæringer og certifikater i forhold til overholdelse af sikkerhedskrav, eksempelvis erklæring efter ISAE 3402. Kunden bør kræve at få fremlagt disse erklæringer og i øvrigt sikre sig

i Kontrakten, at der løbende gives Kunden kopi af erklæringerne. Kunden vil kunne bruge disse i sin egen it-revision. Kunden bør i Kontrakten sikre sig, at der gives meddelelse ved ”incidents”, hvor sikkerheden er blevet brudt eller truet.

Kunden bør efter omstændighederne også se Leverandørens ”disaster reco- very” plan og sammenholde den med sin egen, således at de er koordinerede.

13.2 Kundens egne undersøgelser af sikkerheden, herunder ved audit

Da der ved anvendelse af Cloudløsninger typisk er tale om delte miljøer, vil det ofte give vanskeligheder for Kunden at kunne foretage en egentlig inspektion eller audit af Leverandørens faciliteter. I større aftaler og/eller ved anvendelse af Cloudløsninger til brug for væsentlige, kritiske applikationer, vil Xxxxxx kunne foretage videregående undersøgelser (en form for ”due diligence”) og kræve supplerende oplysninger og dokumentation fremlagt i forhold til de sikkerhedskrav, Xxxxxx måtte stille, navnlig i forhold til beskyttelse af opbe- varet data i Cloudløsningen. Sikkerhed dækker som minimum over følgende forhold:

• Sikkerhed for, at kun de rette får adgang til Kundens data

• Sikkerhed for, at løsningen er tilgængelig

• Sikkerhed for, at Kunden kan få sine data tilbage ved exit

Da der typisk ikke kan opnås en egentlig juridisk og tilstrækkelig sikkerhed for

juridisk opfyldelse (erstatningsansvar) fra Leverandørens side, er Kundens un- dersøgelse og risikovurdering i forhold til Cloudløsningens sikkerhed af central betydning. Kunden må derfor tage stilling til, om resultatet af de foretagne undersøgelser er tilfredsstillende i forhold til Kundens risikovurdering og de gældende lovkrav (persondataloven mv.).

13.3 Virksomhedsspecifikke krav til sikkerhed

Lige som der i relation til spørgsmålet om behandling af data (navnlig person- data), kan der i den enkelte virksomhed være særlige krav til sikkerhed, som skal opfyldes i henhold til vedtagne sikkerhedspolitikker, -standarder og -pro- cedurer. Sådanne politikker mv. kan være baserede på lovkrav, hvilket eksem- pelvis er tilfældet for finansielle virksomheder.

Kunden bør inden indgåelse af Kontrakten få verificeret opfyldelse af sådanne sikkerhedskrav, herunder eksempelvis i forhold til adgangsforhold (særligt administratorrettigheder) såvel elektronisk som fysiskbaseret på egne obliga- toriske sikkerhedskrav.

14.1 Indledning

Et centralt aspekt ved en Cloudløsning er, i hvilket omfang og på hvilken måde det vil være muligt at forlade Cloudløsningen og lade den erstatte af en ny løs- ning hos en anden Leverandør eller via en traditionel it-løsning, som Xxxxxx selv driver.

Lige så vigtigt det er at sikre sig, hvorledes indtræden i Cloudløsningen kan ske (implementering, se afsnit 6 ovenfor), lige så vigtigt er det ved kontrakt- indgåelse at sikre sig, at man også kan komme ud af Cloudløsningen på sikker og effektiv vis og få sine data tilbage.

Kunden bør undersøge og få dokumenteret, hvorledes en exit kan foregå, herunder ved konkret beskrivelse af, hvordan data tilbage- leveres ved ophør. Kunden bør også sikre sig, at der ydes support fra Leverandørens side i forhold til exit.

14.2 Adgang til data efter ophør

Det særlige ved cloud computing er, at der gives en adgang til løsningen, så længe Kontrakten varer. Der er med andre ord ikke mulighed for at fortsætte brugen af Cloudløsningen og få tilgang til data lagret i Cloudløsningen, når Kontrakten ophører.

Kunden bør forholde sig til, hvorledes de opbevarede data kan behand- les, når Kontrakten er udløbet. I visse situationer vil det være muligt for Kunden at forhandle en løsning, hvor der opretholdes en begrænset adgang til Cloudløsningen, således at data fortsat kan opbevares som en form for arkivløsning.

Ved lock-in effekter forstås, at Kunden enten juridisk, teknisk eller kommer- cielt bindes til Leverandøren på en sådan måde, at det enten er umuligt eller vanskeligt for Kunden at skifte til anvendelse af en anden Cloudløsning med samme funktion eller hjemtage funktionen. Lock-in er ikke et fænomen, der kun gælder i forhold til cloud computing, og Kunden bør undersøge, i hvilket omfang der vil være tilsvarende lock-in effekter ved valg af alternativer til cloud computing. Typiske lock-in effekter kan blandt andet være:

• Der er ikke andre leverandører, der udbyder tjenester med den samme funktionalitet som Leverandøren (manglende substitution)

• Kunden har investeret store ressourcer internt og eksternt i forhold til at implementere Cloudløsningen (investering)

• Overgang til en ny Cloudløsning vil kræve en større implementerings- indsats (implementeringsbarrierer)

• Kunden har etableret integrationer mellem Cloudløsningen og sine andre systemer, som ikke kan anvendes ved overgang til en ny Cloud- løsning eller ved hjemtagelse (afhængigheder til andre systemer)

• Data kan ikke udlæses i et anvendeligt format eller kan ikke udlæses på en sådan måde, at de er anvendelige i en ny løsning (datamigre- ringsbarrierer)

• Kunden er bundet af længerevarende bindingsperioder eller opsigel- sesvarsler i Kontrakten (Kontraktbinding)

• Kunden opnår ikke brugsret eller ophavsret til integrationer eller anden kode udviklet særligt til Kunden behov og formål (proprietære barrierer)

Kunden bør forud for indgåelse af Kontrakten undersøge, om Kunden ved anvendelse af Cloudløsningen vil blive låst, enten økonomisk, teknisk eller juridisk på en sådan måde, at Kunden mister handlefrihed, hvis eksempelvis Cloudløsningen ikke udvikles efter Kundens ønsker, eller hvis Leverandøren forhøjer prisen væsentligt.

Kunden kan til en vis grad sikre sig mod lock-in effekter i Kontrakten. Dette kan blandt andet ske ved at indskrive krav om adgang til data ved ophør i formater, som passer til Kunden, og de alternative løsninger, som Kunden kan forvente anvendt i stedet for Cloudløsningen eller sikre brugsret eller ejendomsret til

specialudviklet kode. Kunden kan endvidere sikre sig kommercielt ved at un- dersøge, om der er et modent marked for løsninger inden for det felt, Cloud- løsningen skal virke, således at der er reelle alternativer i markedet.

16 Varighed af Kontrakter

16.1 Uopsigelighedsperiode fra Leverandøren og Kundens side

Det grundlæggende princip ved anvendelse af cloud computing er betaling ud fra forbrug. Dette ændrer dog ikke på, at mange Leverandører opererer med uopsigelighedsperioder (bindingsperioder) og længerevarende opsigelses- varsler. Uopsigelighedsvilkår kan være betingelsen for at opnå særlige priser. Typisk er der relativt korte opsigelsesvarsler i Kontrakter om cloud computing, men dette afhænger af den konkrete Kontrakt. Uanset om der ikke er nogen bindingsperiode og/eller korte opsigelsesvarsler, bør Kunden forholde sig til de lock-in effekter, der er beskrevet i afsnit 15 ovenfor, og som kan være til hinder for, at Kunden i praksis (af økonomiske eller tekniske grunde) vil kunne komme ud af Kontrakten.

Kunden kan på sin side have et behov for at opnå leveringssikkerhed i en læn- gere periode, hvis Kunden har foretaget en investering i det indledende forløb ved at implementere Cloudløsningen, eller der vil være væsentlige omkostnin- ger forbundet med at migrere til en anden løsning. Kunden bør derfor - hvis Kontrakten er genstand for forhandling - sikre sig en uopsigelighedsperiode på nogle år (typisk 2-4 år) samt en ensidig ret til at kunne forlænge varigheden af Kontrakten. Alternativt vil Xxxxxx ikke have sikkerhed for at kunne genvinde de investeringer, som er foretaget ved implementeringen. En uopsigeligheds- periode fra Leverandørens side er således en sikring af, at forretningsgrundla- get for Cloudløsningen (business casen) hænger sammen for Xxxxxx. Endvi- dere sikres Kunden mod kommercielt pres i en genforhandlingssituation, hvis Xxxxxx har en ensidig ret til at forlænge Kontrakten.

I det omfang Kontrakten ikke kan forhandles (og Kunden dermed ikke kan sikre

sig en uopsigelighedsperiode fra Leverandørens side), er Kunden nødsaget til at forlade sig på, at Leverandøren vil fastholde produktet i markedet, og at Kunden selv bærer risikoen for sin investering.

16.2 Ophævelsesmulighed ved misligholdelse

Uafhængigt af vilkårene for opsigelse er vilkårene for ophævelse ved væsentlig misligholdelse. Spørgsmålet om ophævelse er ikke væsentligt i Kontrakter om

Cloudløsninger, hvis de er baseret på udbud af ”on demand” tjenester, som Kunden blot kan ophøre med at bruge med kort eller intet varsel.

Er der derimod tale om kontrakter med længerevarende bindingsperioder, vil det have betydning, at Kunden kan bringe Kontrakten til ophør ved væsentlig misligholdelse. Kunden bør således uanset aftalte opsigelsesvarsler og uop- sigelighedsperioder altid kunne komme ud af Kontrakten ved Leverandørens væsentlige misligholdelse uden varsel eller med et kortere varsel. Typisk er det beskrevet i Kontrakten, hvad der udgør væsentlig misligholdelse. Er vilkå- rene for ophævelse ikke rimelige, og er Kontrakten genstand for forhandling, bør Kunden søge at sikre, at der en ret til at ophæve Kontrakten ved udgang af en afhjælpningsperiode, hvis Leverandøren ikke inden udgangen af denne periode har afhjulpet mangler eller forsinkelse. Kunden bør også sikre sig, at Kunden kan ophæve med et vist varsel, som Xxxxxx selv fastsætter, da det

normalt er urealistisk, at Kunden kan skifte til en anden løsning straks efter op- hævelsen - i særdeleshed hvis den begivenhed, der giver anledning til ophæ- velsen, er en pludselig indtrådt begivenhed.

16.3 Ændringer i vilkår, herunder prisændringer

Ændringer i Kontrakten vil, medmindre andet er aftalt, kræve, at begge parter er enige heri. Det vil sige, at Leverandøren ikke kan ændre i priser, servicemål eller i selve Cloudløsningen, medmindre dette aftales med Kunden.

Da Leverandøren typisk har behov for et vist manøvrerum, vil Leverandøren ofte kræve en ret til at kunne foretage ændringer i ydelsen, men også ofte i selve Kontrakten, herunder i servicemål (SLA). Ændringer i servicemål er et godt eksempel, da det både rammer selve ydelsen, og de vilkår den leveres på.

Ret til at foretage prisændringer er noget, som bør være reguleret i Kontrak- ten. I denne sammenhæng bør det tillige indgå ved vurdering af lock-in effek- terne, som er beskrevet i afsnit 15 ovenfor.

Hvis Kontrakten ikke kan gøres til genstand for forhandling, vil Xxxxxx også på dette punkt være overladt til at foretage en risikovurdering i forhold til risikoen

for at blive mødt med negative ændringer.

Kunden bør undersøge, i hvilket omfang der er en ret for Leverandø- ren til at foretage ændringer i ydelsen, priser og/eller aftalevilkårene, omfanget af denne ret og det varsel, der gælder for at gennemføre ændringer.

16.4 Konkurs og rekonstruktion

Ved indgåelse af Kontrakten bør Kunden også forholde sig til risikoen for, at Leverandøren går konkurs eller tages under rekonstruktion (modpartsrisiko). Disse senarier kan fra Kundens side ses som en form for tvungen exit, og Kun- den bør derfor forholde sig til dette som en del af exitovervejelserne.

Der kan i forbindelse med konkurs eller rekonstruktion opstå særlige problem- stillinger vedrørende adgang til data, og Kunden bør derfor undersøge, hvilke muligheder Xxxxxx har for at kunne hjemtage sine data, hvis Leverandøren af den ene eller anden grund ikke kan eller vil medvirke med ophørsassistance til Kunden under en konkurs eller en rekonstruktionssituation. En mulig løsning på denne problemstilling er at foretage backup, således at data sikres via en tredjepart, men dette indebærer yderligere omkostninger og arbejde for Kun- den, og giver ikke nødvendigvis i alle situationer den nødvendige sikkerhed for adgang til opdaterede data.

I praksis vil det ofte være sådan, at konkursboet eller rekonstruktionen meget hurtigt får solgt Kontrakterne til en ny Leverandør, som således kan videreføre Cloudløsningen. Dette kræver dog, at der er en køber, som vil indtræde, og der er således ikke nogen kommerciel sikkerhed for, at dette vil være tilfældet.

16.5 Særligt om persondata ved ophør

For så vidt angår spørgsmålet om databehandlerens adgang til at behandle

persondata i en Cloudløsning efter aftaleophør, er det vigtigt at være opmærk- som på persondatalovens regler. Det følger således af persondatalovens § 41, stk. 1, at personer, virksomheder mv., der udfører arbejde under den data- ansvarlige eller databehandleren, og som får adgang til oplysninger, kun må behandle disse efter instruks fra den dataansvarlige, medmindre andet følger af lov eller bestemmelser fastsat i henhold til lov.

Denne bestemmelse indebærer således, at såfremt en dataansvarlig meddeler en databehandler instruks om, at persondata, der behandles på vegne af den dataansvarlige, f.eks. skal slettes, har databehandleren en lovfæstet pligt til at efterkomme denne instruks. Denne pligt kan ikke underlægges bestemmelser i parternes indbyrdes aftale, hvorfor databehandleren skal efterkomme en sådan instruks, uanset hvad der måtte følge af aftalegrundlaget mellem den dataansvarlige og databehandleren.

Det bemærkes, at overtrædelse af bestemmelsen i persondatalovens § 41, stk.

1, er strafbelagt.

Aftalen bør derfor indeholde en eksplicit bestemmelse om, at Leverandøren uden undtagelse skal efterkomme alle instruktioner fra Kunden vedrørende data, herunder en instruks om at slette eller udlevere data.

17 Rettigheder til software/applikationer

17.1 Ejendomsret til data

I langt de fleste Kontrakter vedrørende Cloudløsninger fremgår det, at Kunden har den fulde ejendomsret til sine egne data. Hvis ikke dette fremgår direkte

af Kontrakten, bør Kunden søge at få dette angivet. Dette kan være vigtigt i for- hold til at sikre, at Leverandøren ikke anvender Kundens data til andre formål end at levere ydelserne under Cloudløsningen. Hvis data omfatter persondata, skal man være opmærksom på, at det er et grundlæggende krav under per- sondataloven, at Leverandøren alene må anvende data til at levere ydelserne.

17.2 Ejendomsret til software/Cloudløsningen

Det særlige ved cloud computing er, at der ikke som ved traditionelle it-pro- dukter opnås en evigtvarende brugsret til software, men derimod en tidsbe- grænset adgang til at benytte en tjeneste, som baserer sig på software. Det vil sige, at når Kontrakten ophører, har Kunden ikke yderligere ret til at bruge den underliggende software, som anvendes til at levere ydelserne. Som led i implementering af Cloudløsningen kan der være udviklet særlig funktionalitet til Kunden, herunder til brug for grænseflader til andre systemer (API’er). Kun- den bør i Kontrakten sikre sig, at Kunden får adgang til sådan specialudviklet software.

Cloud Computing kontrakter Vejledning om juridiske, kommercielle og tekniske forhold i aftaler om Cloud Computing.

Cloud computing har igennem længere tid været på dagsordenen hos de fleste virksomheder og it-leverandører i Dan- mark og i udlandet. Mange har dog stadig betænkeligheder ved cloud computing og har vanskeligt ved at overskue konsekven- serne ved at anvende løsninger baseret på cloud computing i deres virksomhed.

Cloud computing er ikke ny teknologi, men en anden måde at anvende eksiste- rende teknologi på, hvor brugere på væ- sentlige punkter overlader kontrollen til leverandøren af it-ydelsen og kommer ind i en standardiseret og færdigpakketeret verden af ”services”. Kundens formål med at overlade denne kontrol til Leverandø- ren er at opnå de fordele i form af fleksi- bilitet, skalerbarhed, stabilitet og omkost- ningsbesparelser, som cloud computing i mange tilfælde vil give.

Document Metadata

Table of Contents

Cloud Computing kontrakter

Document Metadata