Skabelon: skønstema i en IT‑sag

Denne skabelon giver en fast struktur til et skønstema i en tvist om et IT-system, logdata eller digitale filer. Den indeholder afsnit om baggrund, materiale og metode og en række eksempelspørgsmål, der kan slettes, kombineres eller omskrives. Skabelonen er et teknisk udgangspunkt fra IT-siden. Den er ikke juridisk rådgivning og skal tilpasses sagen af advokaten, herunder hvad der processuelt kan og bør spørges om.

Hvorfor spørgsmålene skal være tekniske, neutrale og konkrete, er forklaret i artiklen om syn og skøn i IT-sager. Det gentages ikke her.

Sådan bruger du skabelonen

1. Kortlæg data først. Udfyld afsnittet om materiale, før spørgsmålene skrives. Et spørgsmål, der ikke kan kobles til konkrete data, bør omformuleres eller udgå.
2. Udskift alle pladsholdere. Alt i skarpe parenteser skal erstattes med sagens oplysninger eller slettes.
3. Vælg spørgsmål efter sagens kerne. Tag kun de spørgsmålsgrupper med, der passer til tvisten. Tre skarpe spørgsmål er bedre end tyve brede.
4. Fjern markeringerne. Punkter mærket er steder, hvor formuleringen har juridisk betydning. De skal vurderes og fjernes, før temaet sendes.
5. Få en teknisk gennemlæsning. Lad en IT-sagkyndig læse spørgsmålene igennem for besvarlighed, før de sendes til modparten og retten.

Skabelonen

1. Indledning

Sag: [sagens nummer og parter]

Fremsat af: [part], ved [advokat]

Dato: [dato]

Skønsmanden anmodes om at besvare nedenstående spørgsmål på grundlag af det materiale, der er beskrevet i afsnit 3, og en eventuel besigtigelse.

2. Kort teknisk baggrund

Sagen angår [system/datakilde], som [part] har anvendt i perioden [periode fra-til]. Systemet er leveret af [leverandør] og drives [on-premise/i cloud hos leverandør]. Den relevante version er [versionsnummer/dato for release].

Beskrivelsen er neutral og indeholder ikke parternes synspunkter.

3. Materiale til skønsmanden

1. Forensiske kopier: [enhed, serienummer, dato for sikring, hashværdi] med tilhørende sikringsrapport.
2. Logdata: [system], eksporteret den [dato], dækkende perioden [periode fra-til], i formatet [CSV/JSON/andet].
3. Kontraktgrundlag: [kontrakt, kravspecifikation, ændringsaftaler], i den version der er gældende for [dato].
4. Adgang: testmiljø med version [versionsnummer], adgang via [kontaktperson].
5. Øvrigt: [fx tidsregistreringer, sagsstyringssystem, kildekodehistorik].

Materialet overleveres [på krypteret medie/via sikker deling] med hashliste. Spørgsmål om adgang rettes til [kontaktperson].

4. Spørgsmål

Vælg blandt grupperne nedenfor. Hvert spørgsmål nummereres fortløbende i det endelige tema.

A. Funktionalitet og krav

1. Opfylder [system] i version [versionsnummer] kravene i [kravspecifikationens afsnit/punkter]? Skønsmanden bedes for hvert krav angive opfyldt, delvist opfyldt eller ikke opfyldt med begrundelse.
2. Kan de fejl, der er registreret i [fejlregister/sagssystem] i perioden [periode fra-til], reproduceres i testmiljøet? I bekræftende fald, hvilke?

B. Årsag til hændelser

1. Hvad var ifølge logdata fra [system] den tekniske årsag til hændelsen den [dato]? Kan årsagen henføres til (a) applikationen, (b) infrastrukturen, (c) brugerhandlinger, (d) tredjepartskomponenter eller (e) andet?
2. Indeholder det modtagne materiale tilstrækkelige data til at fastslå årsagen? Hvis ikke, hvilke data ville kunne belyse den?

C. Filer og dokumenter

1. Hvornår er filen [filnavn] ifølge dens metadata, filsystemet og eventuel versionshistorik oprettet og senest ændret? Er der uoverensstemmelser mellem disse oplysninger?
2. Er der på [enhed] spor af, at filer fra [mappe/system] er kopieret, uploadet eller sendt til andre placeringer i perioden [periode fra-til]? I bekræftende fald hvilke, hvornår og hvortil?

D. Konti og adgang

1. Hvilke logins til brugerkontoen [konto] fremgår af [logkilde] i perioden [periode fra-til], med tidspunkt, IP-adresse og enhed, i det omfang det er registreret?
2. Er der spor af, at andre end [konto] har haft adgang til [system/fil] i perioden?

E. Timeforbrug og omfang

1. Hvor mange timer er der ifølge [tidsregistrering] anvendt på [opgave], og hvilket timeforbrug vurderer skønsmanden som sædvanligt for en opgave af denne art og kompleksitet?

F. Mails og beskeder

1. Er mailen med emnet [emne], dateret [dato], i [postkasse] ifølge headeroplysninger og serverlogs afsendt fra [konto] og leveret til [konto]? Angiv tidspunkterne med tidszone.
2. Er der i mailens header, vedhæftninger eller metadata tegn på, at den er ændret efter afsendelsen?
3. Findes der i udtrækningen fra [enhed] beskeder i samtalen med [kontakt] i perioden [periode fra-til], som er slettet? Kan slettede beskeder genskabes helt eller delvist?

G. Afsluttende

1. Har skønsmanden i øvrigt bemærkninger til det tekniske grundlag, herunder forhold der taler imod de konklusioner, skønsmanden når frem til?

5. Ønsker til besvarelsen

Skønsmanden bedes for hvert svar angive datagrundlaget, metoden og graden af sikkerhed, og adskille iagttagelser fra vurderinger. Tidsangivelser bedes oplyst med tidszone.

Tilpasning

• Microsoft 365 · Logkilde angives som revisionslog for de navngivne brugere. Oplys licens og opbevaringsperiode, da ældre hændelser kan være væk.
• Google Workspace · Logkilde angives som revisionslogs i administratorkonsollen eller eksport fra Vault, afhængigt af abonnement.
• Mobiltelefon · Materialet er en udtrækning fra telefonen med angivelse af værktøj og udtrækningstype. Spørgsmål om beskeder afgrænses på samtaler og periode.
• Kildekode · Materialet er en kopi af kodedepotet med fuld historik. Spørgsmål om ændringer knyttes til commits, grene og datoer.
• Hosting og drift · Tilføj spørgsmål om oppetid, overvågningsdata og driftsaftalens målepunkter.

Ved Microsoft 365 kan det være relevant at kende opbevaringen i revisionsloggen, før spørgsmålene skrives.

Når modparten også fremsætter spørgsmål

Ofte fremsætter begge parter spørgsmål til samme skønsmand. Læs modpartens spørgsmål med samme tekniske blik som egne:

• Forudsætter spørgsmålet et faktum, der er omstridt? Et spørgsmål som “hvornår slettede medarbejderen filerne” forudsætter, at det var medarbejderen. Foreslå en neutral formulering, fx “hvornår blev filerne slettet, og fra hvilken brugerkonto”.
• Bygger spørgsmålet på materiale, skønsmanden ikke får? Så kan det ikke besvares, og det bør fremgå af materialelisten, hvad der mangler.
• Er perioden eller datakilden afgrænset anderledes end i egne spørgsmål? Uens afgrænsninger giver svar, der ikke kan sammenlignes.
• Er der behov for et supplerende spørgsmål? Hvis modpartens spørgsmål kun belyser én forklaring, kan et opfølgende spørgsmål sikre, at alternative forklaringer også undersøges.

Kontrol før temaet sendes

• ☐ Alle pladsholdere er udskiftet eller slettet
• ☐ Hvert spørgsmål kan kobles til materiale i afsnit 3
• ☐ Ingen spørgsmål indeholder juridiske begreber eller forudsætter omstridte fakta
• ☐ Perioder og tidszoner er angivet ens i hele temaet
• ☐ Versionen af systemet, der spørges til, er bevaret
• ☐ Nummereringen er fortløbende efter sletning af grupper
• ☐ Markeringer til intern brug er fjernet

Typiske fejl

• Spørgsmål om ansvar. Ord som “mangel”, “misligholdelse” eller “skyld” hører hjemme i processkriftet, ikke i spørgsmålene.
• Materialet er ikke sikret. Skønsmanden får en kopieret mappe i stedet for en forensisk kopi, og metadata er gået tabt.
• Forkert version. Systemet er opdateret siden tvisten, og ingen har bevaret den relevante version.
• Alle eksempelspørgsmål er taget med. Temaet bliver langt, dyrt og uskarpt.
• Pladsholdere står tilbage. En overset [dato] eller [system] svækker temaets troværdighed.
• Intet afsluttende spørgsmål. Uden et åbent spørgsmål om modsatrettede forhold kan svarene virke ensidige.

Læs mere

Når skønserklæringen foreligger, skal den læses med samme opmærksomhed på datagrundlag og forbehold. Se Sådan læser du en IT-sagkyndig rapport.

→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig og skønsmand hos Nielco IT