En kunde har bestilt et abonnement i en webshop eller accepteret vilkårene i en portal. Senere opstår der tvist: Kunden siger, at vilkårene aldrig blev vist, at bestillingen ikke var bindende, eller at det slet ikke var kunden, der bestilte. Der er ingen underskrift. Beviset ligger i de spor, systemet efterlod, da aftalen blev indgået.
Kravene til online aftaleindgåelse, fx om oplysninger, bekræftelse og forbrugerbeskyttelse, er advokatens område. Denne artikel handler om, hvilke data der findes, hvad de kan vise, og hvad advokaten bør bede om.
Hvad der skal kunne dokumenteres
I en typisk tvist om en online aftale er der tre spørgsmål:
- Hvem indgik aftalen? Hvilken konto, hvilken person, hvilken enhed?
- Hvad blev der vist og accepteret? Hvilke vilkår, priser og oplysninger stod på skærmen?
- Hvornår skete det, og i hvilken rækkefølge?
Ingen enkelt datakilde svarer på alle tre. Svaret skal samles fra flere.
Datakilder i et ordreflow
- Ordre- eller kundedatabase · Ordren, kunden, tidspunkt, beløb, status, eventuelt markering af accepterede vilkår
- Applikationslog · Hændelser i systemet, fx oprettelse af konto, accept af vilkår, betalingstrin
- Webserverlog · Forespørgsler til bestemte sider med tidspunkt, IP-adresse og browseroplysninger
- Mailsystem eller udsendelsestjeneste · Afsendte ordrebekræftelser og eventuelt om de er leveret
- Betalingsudbyder · Betalingen, kortets eller kontoens oplysninger i begrænset form, eventuel stærk kundeautentifikation
- Versionsstyring af hjemmesiden · Hvilken version af ordreflowet og vilkårene der var i drift på det tidspunkt → Git og kildekode som bevis
→ Bevissikring af webshops og markedspladser
Det svære spørgsmål: hvad stod der på skærmen?
En database kan vise, at kunden satte flueben ved “Jeg accepterer vilkårene”. Den viser sjældent, hvordan siden så ud. Var linket til vilkårene synligt? Hvilken version af vilkårene pegede det på? Var prisen tydelig?
Det kan dokumenteres på flere måder, hver med sine svagheder:
- Versionerede vilkår: Gemmer systemet, hvilken version af vilkårene kunden accepterede, er det et stærkt spor. Mange systemer gør det ikke.
- Kildekodens historik: Versionsstyring kan vise, hvordan ordreflowet var opbygget på en given dato. Det kræver, at koden svarer til det, der faktisk var i drift.
- Gamle skærmbilleder og dokumentation: Interne testbeskrivelser eller skærmbilleder fra tiden kan understøtte, men er sjældent fuldstændige.
- Arkiverede kopier af siden: Offentlige webarkiver kan have gemt sider, men ikke sider bag log-ind eller i et ordreflow.
- Genopbygning: Et testmiljø med den gamle version kan vise flowet, men er en rekonstruktion.
Hvem var det?
At en ordre er afgivet fra en bestemt konto, viser ikke i sig selv, hvem der sad ved skærmen. Spor, der kan styrke identifikationen:
- log-ind med adgangskode eller tofaktor,
- betaling med stærk kundeautentifikation,
- IP-adresse og enhedsoplysninger, sammenholdt med kundens tidligere adfærd,
- ordrebekræftelse sendt til kundens mailadresse uden indsigelse.
Hver for sig er sporene ofte svage. Samlet kan de give et klart billede. → Sessioner, tokens og loginlogs
Hvad logdata ikke viser
Logdata registrerer, hvad systemet gjorde, ikke hvad brugeren forstod. En log kan vise, at siden med vilkårene blev hentet, men ikke at de blev læst. Den kan vise, at en knap blev aktiveret, men ikke om det skete ved en fejl. Den kan heller ikke vise, hvordan siden så ud på en bestemt skærm, fx om en tekst var skjult på en lille mobilskærm. Hvordan sporene skal vægtes i forhold til de aftaleretlige krav, er en juridisk vurdering.
Apps og tredjepartsløsninger
Mange ordreflows bygger på flere leverandører: en platform til webshoppen, en betalingsudbyder, en tjeneste til udsendelse af mails, måske en separat app. Hver leverandør har sine egne data og sin egen opbevaringstid. Klienten har ofte kun adgang til en del af dem via et administrationspanel, og eksportmulighederne er forskellige. Kortlæg derfor tidligt, hvilke leverandører der indgår, og hvordan data kan trækkes ud fra hver af dem.
Spørgsmål til klienten, der driver systemet
Repræsenterer advokaten den virksomhed, der driver webshoppen eller portalen:
- Hvilke systemer indgår i ordreflowet, og hvem driver dem?
- Gemmer systemet, hvilken version af vilkårene kunden accepterede?
- Hvor længe gemmes webserver- og applikationslogs?
- Er ordrebekræftelsen sendt, og kan det dokumenteres?
- Er ordreflowet ændret siden, og er ændringerne dokumenteret?
Logs slettes ofte automatisk efter en periode. Sikr dem, så snart tvisten er kendt. → Logfiler og logrotation
Når klienten er kunden
Repræsenterer advokaten kunden, er der typisk adgang til færre data:
- ordrebekræftelser og andre mails,
- kundens egen konto og ordrehistorik,
- kontoudtog og betalingsoplysninger,
- eventuelle skærmbilleder.
Data fra virksomhedens systemer kan efterspørges ved opfordring eller editionsbegæring. Bed om data, der viser forløbet, ikke kun et resumé. → Editionsbegæring set fra IT-siden
En fornuftig rækkefølge
- Kortlæg de systemer og leverandører, der indgår i ordreflowet.
- Sikr logs, ordredata og mails for den konkrete aftale, før de slettes.
- Fastslå, hvilken version af vilkår og ordreflow der var i drift på aftaletidspunktet.
- Saml sporene i en tidslinje med ensartet tidszone.
- Vurder, hvor der er huller, og om de kan udfyldes med andre kilder.
Gode og dårlige formuleringer
- “Kunden har accepteret vilkårene.” · “Ordredatabasen registrerer accept af vilkår, version [x], den [dato] kl. [tid] fra kontoen [id]. Version [x] fremlægges som bilag [nr.].”
- “Det fremgår af vores system.” · “Udtræk fra applikationsloggen for ordre [nr.], med beskrivelse af, hvordan udtrækket er lavet, fremlægges som bilag [nr.].”
- “Kunden har set prisen.” · “Ordreflowet i den version, der var i drift den [dato], viste prisen på trin [x]. Dokumenteret ved kildekodens historik og testmiljø.”
Hvad en IT-sagkyndig kan undersøge
En IT-sagkyndig kan samle sporene fra de forskellige systemer og vurdere, om de hænger sammen. Konkret kan det være:
- at udtrække de relevante hændelser for den konkrete ordre fra database, applikationslog og webserverlog og beskrive, hvordan udtrækket er lavet,
- at bringe tidspunkter fra forskellige systemer på samme tidszone og opstille dem i en samlet tidslinje,
- at fastslå, hvilken version af ordreflow og vilkår der var i drift på aftaletidspunktet, ud fra versionsstyring og udrulningshistorik,
- at genopbygge ordreflowet i et testmiljø og dokumentere, hvordan det så ud, med tydelig angivelse af, at det er en rekonstruktion,
- at vurdere, om der er huller i logdata, fx perioder uden registreringer, og hvad de kan skyldes.
Den sagkyndige kan derimod ikke fastslå, hvad kunden forstod, eller om oplysningerne var tilstrækkelige i juridisk forstand. Den sagkyndige kan heller ikke bevise, hvem der sad ved skærmen, men kan beskrive, hvor stærkt de samlede spor peger på en bestemt konto, enhed eller forbindelse. Jo tidligere sikringen er sket, jo mere fuldstændigt kan forløbet beskrives.
Typiske fejl
- Der fremlægges et skærmbillede af den nuværende side, ikke den, der var i drift.
- Vilkårenes version på aftaletidspunktet kan ikke fastslås.
- Logs er slettet efter standardopsætningen.
- Et resumé fra systemet fremlægges uden de underliggende data.
- Tidspunkter fra forskellige systemer sammenholdes uden hensyn til tidszoner.
Tjekliste
- ☐ Er alle systemer og leverandører i ordreflowet kortlagt?
- ☐ Er logs, ordredata og ordrebekræftelser sikret?
- ☐ Kan den accepterede version af vilkårene fastslås?
- ☐ Er ordreflowets udseende på aftaletidspunktet dokumenteret?
- ☐ Er tidspunkter fra forskellige systemer bragt på samme tidszone?
→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT
