Typiske tekniske spørgsmål til metoden

Forside › Kvalitet og standarder · Gennemgået oktober 2026 · Af John Nielsen

Når en forensisk undersøgelse bliver prøvet, går de fleste spørgsmål ikke på konklusionen, men på vejen dertil: Hvilket værktøj, hvilken version, hvilken hashalgoritme, hvorfor denne sikringsmetode, hvilken tidszone, hvilke søgninger, og kan fundet være opstået automatisk? Spørgsmålene er forudsigelige, og de bedste svar er skrevet ned, før de bliver stillet: i arbejdsnoterne, i rapportens metodeafsnit og i bilagene. Advokatens side af sagen, altså hvordan spørgsmålene bruges i en afhøring, er beskrevet i Krydsforhør af en IT-sagkyndig. Denne artikel ser på de samme spørgsmål fra den sagkyndiges stol: hvad der bliver spurgt om, hvorfor, og hvilken dokumentation der svarer.

Overblik

Værktøj · Typisk spørgsmål: Hvilket værktøj og hvilken version? · Dokumentation, der svarer: Metodeafsnit, værktøjsregister
Validering · Typisk spørgsmål: Hvordan ved du, at værktøjet viser det rigtige? · Dokumentation, der svarer: Testresultater, manuel kontrol af fund
Hash · Typisk spørgsmål: Hvilken algoritme, hvad er hashet, hvornår kontrolleret? · Dokumentation, der svarer: Hashlog, sikringsrapport
Sikring · Typisk spørgsmål: Hvorfor denne metode og ikke en anden? · Dokumentation, der svarer: Begrundelse i noter og rapport
Tid · Typisk spørgsmål: Hvilken tidszone, er uret kontrolleret? · Dokumentation, der svarer: Notat om referencetid, tidszone pr. kilde
Afgrænsning · Typisk spørgsmål: Hvem valgte søgeord og periode? · Dokumentation, der svarer: Opdrag, kommissorium, søgelog
Fortolkning · Typisk spørgsmål: Kan sporet opstå af sig selv? · Dokumentation, der svarer: Vurdering af alternative forklaringer
Egne spor · Typisk spørgsmål: Har undersøgelsen ændret noget? · Dokumentation, der svarer: Handlingslog, beskrivelse af live-arbejde

Værktøj og version

Spørgsmålet “hvilket værktøj brugte du?” er sjældent det egentlige spørgsmål. Det egentlige er, om værktøjet kan have vist noget forkert. Et godt svar indeholder derfor tre ting: navn og version, hvorfor netop det værktøj er egnet til datatypen, og hvordan de fund, konklusionen hviler på, er kontrolleret, fx manuelt i de rå data eller med et andet værktøj.

Bliver du spurgt, om der findes kendte fejl i versionen, så svar ud fra det, du ved og har undersøgt. Har du ikke undersøgt det, er det svaret. Det er bedre at have kontrolleret de afgørende fund uafhængigt af værktøjet end at kunne remse alle versioners rettelser op. → Verifikation af værktøjer

Hashværdier

Typiske spørgsmål:

Hvilken algoritme blev brugt, og hvorfor?
Hvad dækker hashværdien: hele mediet, et logisk udtræk eller enkelte filer?
Hvornår blev værdien beregnet, og hvornår blev den kontrolleret igen?
Hvorfor kan hashværdien af en mobil- eller cloudeksport ikke gentages?

Det sidste spørgsmål kommer ofte, og svaret skal være forberedt. En logisk eksport fra en telefon eller en cloudtjeneste ændres, hver gang den foretages, fordi systemet er i brug, og eksporten indeholder tidspunkter og metadata fra selve kørslen. Hashværdien sikrer det eksporterede sæt fra det øjeblik, det er lavet, ikke kilden.

Datagrundlag og kæde af ansvar (chain of custody)

Før metoden kommer data. Typiske spørgsmål:

Hvem sikrede dataene, og var du selv til stede?
Har parten selv eksporteret noget af materialet, og er det i givet fald kontrolleret?
Hvor har kopierne været opbevaret, og hvem har haft adgang?
Hvilke data blev ikke udleveret eller kunne ikke sikres?

Svarene ligger i chain of custody-loggen og i sikringsrapporten. Er der et hul, fx en periode, hvor en kopi lå hos opdragsgiver, så sig det, og forklar, hvordan hashkontrollen alligevel viser, at kopien er uændret, hvis den gør det. Materiale, som en part selv har eksporteret, bør altid beskrives som sådan, også selv om det er kontrolleret bagefter.

Valg af sikringsmetode

“Hvorfor lavede du ikke en fuld kopi?” er et af de mest effektive spørgsmål, hvis svaret ikke er forberedt. Begrundelsen kan være teknisk (enheden understøtter det ikke, data ligger i cloud), proportional (afgrænsning af hensyn til private data og opdraget) eller praktisk (tid og adgang). Den skal stå i noterne fra sikringstidspunktet, og konsekvensen for, hvad rapporten kan udtale sig om, skal stå i begrænsningerne. → Fysisk, logisk eller målrettet sikring

Tid

Spørgsmål om tid er hyppige, fordi fejl her kan vende en rækkefølge:

Hvilken tidszone er tidspunkterne i rapporten angivet i?
Var der kilder i lokal tid, og hvordan blev de omregnet?
Blev enhedens ur sammenlignet med en pålidelig kilde, og hvad var afvigelsen?
Kan to hændelser fra forskellige kilder ordnes sikkert, når de ligger få sekunder fra hinanden?

Svarene skal kunne gives præcist. “Det tjekkede jeg” er svagt. “Urets afvigelse var under et sekund ved sikringen, jf. note fra kl. 10:12” er stærkt.

Afgrænsning og søgninger

Hvem valgte søgeordene, perioden og de undersøgte kilder? Blev der også søgt efter det, der kunne tale imod konklusionen? Har søgningerne taget højde for bøjningsformer, stavevarianter og danske tegn? Har du en søgelog med de præcise søgninger, værktøjet og antallet af træffere, kan spørgsmålene besvares konkret. Var søgeordene leveret af opdragsgiver, skal det fremgå. → Søgetermer teknisk

Fortolkning

Her ligger de spørgsmål, der rammer konklusionen direkte:

Kan sporet opstå ved synkronisering, antivirus, indeksering eller backup?
Viser artefaktet, at filen blev kopieret, eller kun at den blev åbnet?
Viser loggen en person eller en konto?
Hvad ville du forvente at finde, hvis modpartens forklaring var rigtig?

Det sidste spørgsmål er det sværeste, og det er det, en grundig undersøgelse allerede har stillet sig selv. Har rapporten et afsnit om alternative forklaringer, kan svaret henvise dertil.

Egne spor og kontaminering

Har du arbejdet på et tændt system, logget ind på en konto eller monteret et medie, kan du blive spurgt, om din egen aktivitet kan forveksles med den aktivitet, sagen handler om. Svaret kræver en handlingslog med tidspunkter og en beskrivelse af, hvilke spor handlingerne efterlod, og hvordan de er holdt adskilt. → Kontaminering: når undersøgelsen selv efterlader spor

Reproducerbarhed

“Kan en anden sagkyndig gentage din undersøgelse og nå samme resultat?” Svaret er ja, når hashværdier, præcise stier og poster, værktøjer og versioner samt søgninger er dokumenteret. Er en del af undersøgelsen ikke gentagelig, fx arbejde på et system, der siden er ændret, skal det siges, og fremgangsmåden skal være beskrevet i detaljer.

Kompetence og uvildighed

Spørgsmål om erfaring med netop denne platform eller logkilde er legitime. Svar konkret og inden for det, du faktisk har arbejdet med. Spørgsmål om uvildighed, fx hvem der har bestilt undersøgelsen, og hvilken kontakt der har været med parten, besvares bedst med henvisning til dokumenterede, metodiske værn: skriftligt opdrag, adskillelse af fakta og vurdering og behandling af alternative forklaringer. → Uvildighed i praksis

Spørgsmål om omkostninger og tidsforbrug kan også komme, fx om undersøgelsen var for begrænset til at nå et bestemt resultat. Svar ud fra opdraget og afgrænsningen: hvad der blev aftalt, hvilke kilder der blev prioriteret og hvorfor. En prioritering, der er begrundet og skrevet ned på tidspunktet, er lettere at forklare end en, der skal rekonstrueres bagefter.

Forbered dig

Læs din egen rapport som en modpart, og skriv de ti mest oplagte spørgsmål ned.
Find for hvert spørgsmål den note, det bilag eller den logpost, der svarer.
Notér de punkter, hvor svaret er “ikke undersøgt” eller “kan ikke vises”, og øv at sige det kort.
Kontrollér, at versioner, hashværdier og tidspunkter i rapporten stemmer med noterne.
Afstem med opdragsgiver, hvilke dokumenter der er fremlagt, så du ved, hvad du kan henvise til.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Kvalitet og standarder

Læs også: Teknisk forklaring i retten: hash, tidsstempler og logs for ikke-teknikere · IR-rapporten som bevis: hvad mangler, når den skal bruges i en tvist?

→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik