En SaaS-tvist adskiller sig fra en klassisk IT-leverancetvist på ét afgørende punkt: Systemet kører hos leverandøren. Kunden har ingen server, ingen logfiler og ofte kun et brugerinterface. Leverandøren har næsten alle de data, der kan vise, om tjenesten har levet op til aftalen. Det skæve udgangspunkt præger hele bevisførelsen.
Tvisten handler typisk om oppetid, svartider, supportreaktion, datatab eller adgang til data ved ophør. Hvordan SLA’en og ansvarsbegrænsninger skal fortolkes, er advokatens felt. Her ser vi på, hvad der kan måles og dokumenteres.
Start med definitionerne i SLA’en
En SLA er kun så præcis som dens definitioner. Før der indsamles data, skal advokaten og den sagkyndige være enige om, hvad aftalen faktisk måler.
- Oppetid · Måles den pr. måned, kvartal eller år? Hvilke tjenester og funktioner indgår?
- Planlagt vedligehold · Er det undtaget, og hvordan skal det varsles?
- Nedbrud · Er det totalt udfald, eller tæller langsom eller delvis funktion også med?
- Målepunkt · Måles der hos leverandøren, i et netværkspunkt eller hos brugeren?
- Responstid · Er det tid til første svar, til løsning eller til en midlertidig omgåelse?
Et eksempel: Leverandøren rapporterer høj oppetid, fordi serveren svarede hele tiden. Kunden oplevede, at login fejlede i flere timer. Begge kan have ret, hvis SLA’en kun måler, om serveren svarer. Uenigheden handler så om definitionen, ikke om dataene.
Hvor data ligger
Hos leverandøren:
- Overvågningsdata og interne målinger af oppetid og svartider
- Applikations- og fejllogs
- Hændelsesrapporter og interne analyser efter nedbrud
- Supportsystemets sager med tidsstempler
- Statussiden og dens historik
- Backup og logs over sletning eller gendannelse af kundens data
Hos kunden:
- Supportsager, som de ser ud i kundeportalen
- Mails og chats med leverandøren under hændelsen
- Interne beskeder om, at systemet ikke virkede
- Egen overvågning, hvis kunden har den
- Data om forretningskonsekvenser: ordrer, der ikke kunne behandles, medarbejdere, der ikke kunne arbejde
- Integrationslogs fra kundens egne systemer, der kalder tjenesten
Den sidste kategori overses ofte. Hvis kundens økonomisystem eller webshop er koblet til tjenesten, kan dens logs vise fejlede kald og svartider set fra kundens side. Det er en uafhængig kilde, der ikke er kontrolleret af leverandøren. → Logfiler og logrotation
Det skal sikres først
- Statussiden og hændelsesrapporter: Gem dem, som de ser ud nu, med dato og URL. Leverandøren kan redigere eller fjerne dem. → Gem en webside som dokumentation
- Kundeportalen: Eksportér supportsager med historik, så længe adgangen virker.
- Kundens egne logs: Integrationer, proxy og firewall roterer ofte hurtigt.
- Kundens data i tjenesten: Hvis aftalen ophører, kan data blive slettet efter en periode. Lav en fuld eksport, før det sker. → Opsigelse af IT-leverandør: sikr data
- Den aftalte version af vilkårene: SaaS-vilkår ændres løbende online. Find den version, der gjaldt i perioden.
Det sidste punkt er vigtigt. Mange tjenester henviser til vilkår og SLA på en webside, som opdateres uden at blive sendt til kunden. Gem den aktuelle version, og undersøg om ældre versioner kan findes i klientens arkiv eller i offentlige webarkiver.
Når leverandøren har dataene
Leverandørens interne målinger er typisk det bedste bevis for, hvad der skete i systemet. Det er også det bevis, kunden har sværest ved at efterprøve. Tre ting kan styrke kundens position:
- Tidlig anmodning om bevarelse: Et skriftligt krav om, at bestemte logs og målinger bevares.
- Edition: Hvis leverandøren ikke udleverer frivilligt. Gør anmodningen konkret: hvilke data, hvilken periode, hvilket format. → Editionsbegæring set fra IT-siden
- Rådata frem for rapporter: En SLA-rapport er en opsummering. Bed om de målinger, rapporten er beregnet ud fra, så en sagkyndig kan efterregne.
Ligger leverandørens data uden for EU, eller er leverandøren en stor international platform, kan det tage tid at få data udleveret. → Beviser i cloud uden for EU
Hvad data kan og ikke kan vise
- Logs kan vise fejlede forespørgsler, svartider og tidspunkter for nedbrud.
- Logs kan normalt ikke alene vise årsagen til et nedbrud. Den kræver leverandørens hændelsesanalyse eller en sagkyndig gennemgang af systemet.
- Kundens egne beskeder om, at “systemet var nede”, viser oplevelsen, men ikke nødvendigvis omfanget eller varigheden.
- En leverandørs hændelsesrapport er en partsforklaring. Den kan være præcis, men den er skrevet af den part, der har interesse i udfaldet.
- Data om forretningskonsekvenser kan belyse et tab, men hvilke tab der kan kræves dækket, er et juridisk spørgsmål.
Når tvisten handler om tabte data
Nogle SaaS-tvister handler ikke om oppetid, men om data, der er forsvundet eller ødelagt. Så flytter spørgsmålene sig. Hvornår blev data sidst set intakt? Hvilken bruger eller proces ændrede eller slettede dem? Fandtes der en backup, og blev der forsøgt gendannelse?
Kunden kan ofte selv bidrage med ældre eksporter, rapporter eller udtræk, der viser, hvordan data så ud på et bestemt tidspunkt. Sammenholdt med den nuværende tilstand kan de afgrænse, hvad der mangler. Leverandørens revisionslog og backuplog er den anden halvdel, og den skal normalt bestilles konkret.
Hvad en IT-sagkyndig kan efterregne, og hvad ikke
Med adgang til rådata kan en IT-sagkyndig typisk:
- efterregne oppetiden efter SLA’ens egen definition og sammenligne med leverandørens rapporter,
- sammenholde leverandørens målinger med kundens integrationslogs og egen overvågning og beskrive, hvor de stemmer overens, og hvor de afviger,
- opstille en tidslinje over hændelser, supportsager og svar fra leverandøren med ensartet tidszone,
- vurdere, om der er perioder, hvor målingerne mangler, og hvad hullerne betyder for opgørelsen,
- beskrive, hvilke yderligere data der skal til for at kunne sige noget om årsagen til et nedbrud.
Den sagkyndige kan derimod ikke efterregne noget, der ikke er målt. Har ingen af parterne registreret svartider for en bestemt funktion, kan det ikke rekonstrueres bagefter. Den sagkyndige kan heller ikke afgøre, hvordan SLA’en skal fortolkes, hvis definitionen er uklar. Så kan det være nødvendigt at beregne oppetiden efter flere mulige definitioner og lade retten tage stilling til, hvilken der gælder. Det giver et mere brugbart grundlag end ét tal, der bygger på en omtvistet forudsætning.
Typiske fejl
- Kunden har ikke sikret statussiden, og leverandøren har senere omskrevet hændelsen.
- Kun skærmbilleder af supportsager, uden tidsstempler og svartider.
- Kundens integrationslogs er slettet, fordi ingen vidste, at de var relevante.
- Data er ikke eksporteret før ophør, og kontoen er lukket.
- Ingen har afklaret, hvordan SLA’en definerer oppetid, før der regnes på den.
Spørgsmål til klienten
- Hvordan og hvornår opdagede I problemerne?
- Har I egne systemer, der taler med tjenesten?
- Hvilke supportsager er oprettet, og hvem oprettede dem?
- Hvilken version af vilkårene accepterede I, og hvordan?
- Har I en fuld eksport af jeres data?
Spørgsmål til skønsmanden
- “Kan det ud fra de udleverede målinger og kundens integrationslogs opgøres, hvor længe tjenestens loginfunktion var utilgængelig i den angivne periode?”
- “Er leverandørens beregning af oppetid foretaget i overensstemmelse med SLA’ens definition, og giver de underliggende målinger samme resultat?”
- “Hvilke data om årsagen til nedbruddet fremgår af det udleverede materiale, og hvad mangler for at kunne fastslå årsagen?”
Indeholder vilkårene en voldgiftsklausul, gælder de samme tekniske overvejelser. → Digitale beviser i voldgift
→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT
