Tjekliste: IT‑leverancesag

Tvister om IT-leverancer handler sjældent om ét enkelt bevis. De afgøres af, om man kan vise, hvad der var aftalt, hvad der blev leveret, og hvad der skete undervejs. Dokumentationen ligger spredt i ticketsystemer, kodedepoter, testmiljøer, logs og mails, og meget af den forsvinder, når projektet lukkes ned, eller samarbejdet ophører. Denne tjekliste samler de punkter, advokaten bør gennemgå med klienten, uanset om klienten er kunde eller leverandør. Den er et teknisk udgangspunkt, ikke juridisk rådgivning, og skal tilpasses sagen af advokaten.

Hvordan dokumentationen bruges i retssagen, er forklaret i Mangler ved IT-leverancer: dokumentation i retssagen. Er klienten leverandøren, se også Når klienten er IT-leverandøren.

Sådan bruger du tjeklisten

1. Afklar klientens rolle først. Kunde og leverandør har adgang til forskellige data. Mange punkter skal derfor afklares som “hvem har det?”.
2. Prioritér det, der lukker ned. Testmiljøer, prøvelicenser og projektværktøjer har ofte en udløbsdato. De står i afsnit 3.
3. Brug listen til datakortet. Svarene kan skrives direkte ind i et datakort.

Tjekliste

1. Aftalegrundlaget

• ☐ Kontrakt med bilag er modtaget i den underskrevne version. Kilde: [signeringstjeneste/mail/papir].
• ☐ Kravspecifikation og løsningsbeskrivelse er modtaget i den version, der var gældende ved kontraktindgåelsen.
• ☐ Senere versioner af specifikationen er identificeret, med dato og ophav.
• ☐ SLA og servicebeskrivelse er modtaget, hvis driften er omfattet.
• ☐ Det er noteret, hvor aftalte ændringsønsker er registreret: [mail/ticketsystem/styregruppereferater].

2. Projektforløbet

• ☐ Ticketsystem (Jira, Azure DevOps, Zendesk eller andet): navn, ejer og hvem der har administratoradgang. Se Jira, Zendesk og ticketsystemer som bevis.
• ☐ Eksport af tickets for perioden [fra] til [til] med fuld historik, ikke kun den aktuelle status.
• ☐ Styregruppe- og projektmødereferater med dato og deltagere.
• ☐ Projektkalender og milepælsplaner i de versioner, der blev udsendt.
• ☐ Chat mellem parterne (Teams, Slack) er omfattet af bevarelse.
• ☐ Mails mellem nøglepersoner er omfattet af bevarelse. Navne: [liste].

3. Det, der kan lukke ned

• ☐ Testmiljø og staging: findes de stadig? Hvem betaler for dem, og hvornår lukkes de?
• ☐ Projektværktøjer med abonnement: udløbsdato [dato].
• ☐ Logs fra drift og overvågning: opbevaringstid [x dage]. Eksport af perioden [fra] til [til] er bestilt.
• ☐ Brugeradgange hos modparten: lukkes de, når samarbejdet ophører? Dokumentér det, der kan ses, før adgangen forsvinder.
• ☐ Det er vurderet, om modparten skal have en meddelelse om bevarelse. Se Skabelon: meddelelse om bevarelse af data.

4. Det leverede

• ☐ Kildekode: placering [Git-tjeneste/server], og om der er adgang til fuld historik, ikke kun seneste version.
• ☐ Releases og versioner: hvilken version blev leveret til test, og hvilken blev sat i drift? Med dato.
• ☐ Konfiguration: opsætning af det leverede system på leveringstidspunktet, hvis den kan genskabes.
• ☐ Dokumentation: brugervejledninger, driftsvejledninger og installationsbeskrivelser i leverede versioner.
• ☐ Det er afklaret, om kildekoden er deponeret hos tredjemand, og på hvilke vilkår.

5. Test og godkendelse

• ☐ Testplaner og testcases i den version, der var aftalt.
• ☐ Testresultater med dato og tester, herunder fejlrapporter.
• ☐ Godkendelser og forbehold: mails eller formularer, hvor testen blev godkendt eller afvist.
• ☐ Fejllister ved overtagelse, med prioritet og status over tid.
• ☐ Det er noteret, om klienten selv har lavet test efter overtagelsen, og hvordan det er dokumenteret.

6. Drift og oppetid

• ☐ Overvågningsdata for oppetid og svartider fra [værktøj], med kendt tidszone.
• ☐ Hændelseslog og incidentrapporter.
• ☐ Det er afklaret, om oppetiden måles af leverandøren, af kunden eller af en tredjemand. Målepunktet kan give forskellige tal. Se SaaS-tvister: oppetid, SLA og logdata.

7. Ophør og exit

• ☐ Det er noteret, hvilke data der skal udleveres ved ophør, i hvilket format og hvornår.
• ☐ Der er en plan for kontrol af en dataudlevering: antal poster, felter og stikprøver.
• ☐ Ophørsdato og sletning hos modparten er kendt. Se Exit-bistand og dataudlevering.

8. Overblik

• ☐ Klientens påstande er delt op i de tre spørgsmål: hvad var aftalt, hvad blev leveret, og hvad skete der undervejs.
• ☐ For hver påstand er der mindst én datakilde, der kan belyse den.
• ☐ Det er afklaret, om der skal indhentes en partsindhentet IT-erklæring nu, eller om syn og skøn er det rigtige.

Spørgsmål til klienten i det første møde

• Hvornår begyndte uenigheden, og hvad var den første skriftlige tilkendegivelse om den?
• Hvem hos klienten og hos modparten var de faste kontaktpersoner, og er nogen af dem stoppet?
• Bruger parterne samme ticketsystem, eller har hver part sit eget?
• Er der planlagt ændringer, som kan påvirke data, fx overgang til ny leverandør, opgradering eller nedlukning af et miljø?
• Har klienten selv lavet opgørelser over fejl eller oppetid, og hvordan er de lavet?
• Er der indgået aftaler om ændringer i møder, som ikke er skrevet ned?

Svarene afgør, hvilke afsnit i tjeklisten der haster, og hvilke personer bevarelsen skal omfatte.

Praktisk rækkefølge

1. Afsnit 3 først. Det, der kan lukke ned, sikres, før noget andet gennemgås.
2. Derefter afsnit 1 og 4. Aftalegrundlaget og det leverede danner rammen for resten.
3. Så afsnit 2, 5 og 6. Forløbet, testen og driften belyser, om leverancen holdt.
4. Afsnit 7 løbende. Ophør kan ske midt i sagen og skal kunne kontrolleres, når det sker.
5. Afsnit 8 til sidst. Overblikket laves, når datakilderne er kendt.

Hvad en IT-sagkyndig kan undersøge, og hvad der ikke kan konkluderes

En IT-sagkyndig kan genskabe en leveret version i et testmiljø og vise, om en fejl kan reproduceres. Den sagkyndige kan gennemgå historik i kodedepot og tickets og vise, hvornår en fejl blev meldt, rettet eller lukket, og om historikken er ændret. Oppetidstal fra forskellige værktøjer kan sammenholdes, når målepunkt og tidszone er kendt.

Det kan ikke konkluderes ud fra data alene, hvad der var aftalt, når aftalen er uklar. Den sagkyndige kan beskrive, hvad systemet gør, og sammenholde det med en specifikation, men fortolkningen af specifikationen er et juridisk spørgsmål. → Syn og skøn i IT-sager

Tilpasning

• Klienten er kunden · Mange data ligger hos leverandøren. Fokus på egne mails, egne test og egne adgange, og på hvad der skal begæres fremlagt.
• Klienten er leverandøren · Fuld adgang til kode og tickets, men også pligt til at bevare dem. Undgå oprydning i repositories og tickets.
• Standardsystem med tilpasninger · Adskil fejl i standardproduktet fra fejl i tilpasningerne. Bed om versionsnumre på begge.
• Agilt projekt uden fast specifikation · Backlog, sprintplaner og demo-optagelser bliver det centrale aftalegrundlag. Sikr dem med historik.
• AI-komponent · Modelversion, træningsdata og evalueringer skal identificeres. Se AI-leverancer.

Typiske fejl

• Kun den nyeste version af specifikationen sikres. Tvisten handler ofte om, hvad der stod på et bestemt tidspunkt.
• Tickets eksporteres uden historik. Status, ansvarlig og prioritet kan være ændret mange gange.
• Testmiljøet lukkes. Så kan fejlen ikke længere vises i den version, der blev leveret.
• Ryddet repository. Sletning af grene eller omskrivning af historik efter tvistens start skaber tvivl om alt det andet.
• Oppetid måles forskelligt. Parterne fremlægger tal fra hver sit værktøj uden at afklare målepunkt og tidszone.
• Mundtlige aftaler om ændringer. Find referater, mails eller tickets, der bekræfter dem, mens deltagerne kan huske, hvor de ligger.

→ Haster det? Sådan sikres beviserne nu · Tlf. 70 13 63 23 · Digital bevissikring for advokater hos Nielco IT