Skabelon: editionsbegæring om mails og logdata

Denne skabelon dækker den tekniske beskrivelse i en editionsbegæring: hvilke mails og logdata der ønskes fremlagt, fra hvilke kilder, for hvilke personer og perioder, og i hvilket format. Den juridiske del, herunder hjemmel, bevistema og begrundelse for relevans, er ikke med. Skabelonen er et teknisk udgangspunkt, ikke juridisk rådgivning, og skal tilpasses sagen af advokaten.

Baggrunden for, hvorfor en begæring skal være præcis, og hvordan modpartens IT kortlægges, står i artiklen om editionsbegæring set fra IT-siden.

Sådan bruger du skabelonen

1. Kortlæg modpartens systemer først. Udfyld datakilderne ud fra det, klienten allerede ved, fx mailheadere, delte links og fakturaer.
2. Udfyld én blok pr. datakilde. Mails og logdata beskrives hver for sig. Er der flere postkasser, gentages blokken.
3. Afprøv søgeordene. Kør dem på klientens egne mails fra samme forløb, før de skrives ind.
4. Indsæt kun det tekniske i begæringen. Den juridiske ramme skrives af advokaten. Fjern alle-noter, når de er vurderet.

Skabelonen

Del 1: Mails

Datakilde: Postkassen tilhørende [navn], [mailadresse], i [Microsoft 365/Google Workspace/egen mailserver/andet].

Omfattede mapper: Alle mapper i postkassen, herunder indbakke, sendt post, slettet post, arkiv og eventuelle undermapper [eller: afgrænset til mapperne [navne]].

Periode: Mails sendt eller modtaget fra og med [dato] til og med [dato].

Indhold: Mails, hvor mindst ét af følgende er opfyldt:

1. Afsender eller modtager (til, cc eller bcc) har domænet [domæne.dk] eller adressen [mailadresse].
2. Emnefelt eller brødtekst indeholder et af søgeordene [søgeord 1], [søgeord 2], [søgeord 3], herunder varianter [variant].
3. En vedhæftet fil har filnavnet [filnavn] eller indeholder et af søgeordene.

Vedhæftede filer: Fremlægges sammen med den mail, de hører til, i oprindeligt format.

Format: Hver mail fremlægges som original fil (.eml eller .msg) med fuld header, eller som eksport fra mailsystemets søgefunktion i et format, der bevarer header og metadata. Udskrifter og PDF-konverteringer opfylder ikke begæringen.

Del 2: Logdata

Datakilde: [revisionslog i Microsoft 365/revisionslogs i Google Workspace/log fra system [navn]], for organisationen [navn eller domæne].

Brugerkonti: [brugernavn 1], [brugernavn 2].

Periode: Hændelser registreret fra og med [dato] til og med [dato].

Hændelsestyper: Afgrænset til hændelser om:

1. log ind og log ud, med tidspunkt, IP-adresse og klient eller enhed,
2. download, synkronisering og kopiering af filer,
3. deling af filer og mapper, herunder oprettelse af links,
4. sletning og gendannelse af filer og mails,
5. [andre hændelsestyper, fx videresendelsesregler eller ændringer af rettigheder].

Format: Eksport i maskinlæsbart format (CSV eller JSON) med alle felter, som systemet registrerer for hændelsen. Tidsangivelser med oplysning om tidszone.

Del 2a: Dokumenter i fildeling (valgfri)

Datakilde: [SharePoint-websted/OneDrive for [navn]/Google Drev/fildeling [navn]], for organisationen [navn eller domæne].

Placering: Mappen [sti eller navn] med undermapper [eller: dokumenter, hvor [navn] er ejer eller har redigeret].

Periode: Dokumenter oprettet eller ændret fra og med [dato] til og med [dato].

Versioner: Alle gemte versioner af hvert dokument i perioden, ikke kun den aktuelle.

Format: Dokumenterne fremlægges i oprindeligt filformat sammen med en oversigt fra systemet over versioner med tidspunkt og bruger, der har gemt den enkelte version. Konverteringer til PDF opfylder ikke begæringen.

Del 3: Redegørelse for udtrækket

Fremlæggelsen ledsages af en kort skriftlig redegørelse, der oplyser:

1. Hvem der har foretaget udtrækket, og i hvilken egenskab.
2. Hvornår udtrækket er foretaget.
3. Hvordan: hvilket system og hvilken funktion der er brugt.
4. Søgekriterier præcis som de er indtastet.
5. Antal: hvor mange elementer søgningen gav, og hvor mange der er fremlagt.
6. Udeladelser: om noget er udeladt, og med hvilken begrundelse.
7. Opbevaring: om data for dele af perioden ikke længere findes, og i givet fald hvorfor.

Integritet: Der vedlægges en liste over de fremlagte filer med hashværdi (SHA-256).

Del 4: Fortrolighed (valgfri)

Indeholder postkassen eller logdata forretningshemmeligheder eller oplysninger om personer uden for sagen, foreslås det, at søgningen foretages af [uvildig IT-sagkyndig], som alene udleverer de elementer, der opfylder kriterierne i del 1 og 2.

Varianter

• Google Workspace · Datakilden angives som Gmail-kontoen. Formatet kan angives som eksport fra Google Vault, hvis modparten har det. Mapper svarer til etiketter.
• Egen mailserver · Bed om eksport fra serveren i et standardformat og om serverens logfiler for afsendelse og modtagelse i perioden.
• Teams eller Slack · Angiv kanaler eller samtaler og deltagere frem for postkasser. Bed om eksport, der bevarer tidsstempler og afsender.
• Telefon i stedet for mail · Datakilden er telefonnummer [x] og apps [SMS/WhatsApp/andet]. Indhold afgrænses til samtaler med [nummer/kontakt]. Bed om udtræk med et anerkendt værktøj frem for skærmbilleder.
• Tredjemand som indehaver · Er data hos en leverandør eller tidligere arbejdsgiver, beskrives systemet og kontoen, så den pågældende kan finde data uden kendskab til sagen.

Ved logdata fra Microsoft 365 er opbevaringsperioden begrænset og afhænger af licens. Se Unified Audit Log i Microsoft 365, før perioden fastlægges. For Google Workspace, se Google Vault og revisionslogs.

Spørgsmål til klienten før udfyldning

Mange pladsholdere kan kun udfyldes med klientens hjælp. Stil spørgsmålene, før begæringen skrives:

• Hvilke mailadresser og domæner har modparten brugt i forløbet, også private adresser?
• Hvilke personer hos modparten har deltaget, og hvem var cc på de vigtigste mails?
• Hvilke ord, projektnavne, ordrenumre eller filnavne gik igen i korrespondancen?
• Hvornår begyndte forløbet, og hvornår blev det til en tvist?
• Har modparten delt filer via links, og hvilken tjeneste kom linkene fra?
• Er der tegn på, at modparten bruger Microsoft 365 eller Google Workspace, fx i mailheadere, mødeinvitationer eller fakturaer?

Svarene gør det muligt at afgrænse begæringen, så den kan efterkommes, uden at den bliver så snæver, at det centrale glider ud.

Kontrol før begæringen indgives

• ☐ Hver datakilde har sin egen blok med periode, personer og format
• ☐ Perioden har både start- og slutdato
• ☐ Søgeordene er afprøvet på klientens egne mails
• ☐ Bcc, slettet post og arkiv er nævnt udtrykkeligt
• ☐ Hændelsestyper i logdata er afgrænset
• ☐ Krav om redegørelse og hashliste er medtaget
• ☐ Alle pladsholdere og interne noter er fjernet

Typiske fejl

• Periode uden slutdato. “Fra [dato] og frem” giver en begæring, der vokser, mens sagen kører.
• Søgeord, der rammer alt. Et kort projektnavn eller et almindeligt ord kan give tusindvis af træffere.
• Bcc og slettet post er glemt. Mails, der er sendt i bcc eller slettet, kommer ikke med, hvis det ikke fremgår.
• Logdata uden hændelsestyper. Uden afgrænsning kan modparten fremlægge en meget stor log, der reelt ikke kan gennemgås.
• Ingen redegørelse. Uden oplysning om søgekriterier og antal er det svært at vurdere, om fremlæggelsen er fuldstændig.
• Tidszone mangler. Logdata i UTC sammenholdt med mails i dansk tid giver tilsyneladende uoverensstemmelser.

Når det fremlagte modtages

Sammenhold det fremlagte med begæringen blok for blok: perioden, personerne, søgeordene og formatet. Kontrollér hashværdierne mod listen, og notér huller i perioden og halve mailtråde. Hvordan en kontrol gribes an, er beskrevet i artiklen om editionsbegæringer, der er linket øverst. Hvis data er gået tabt, kan det hænge sammen med manglende bevarelse og litigation hold.

→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT