Forside › Kvalitet og standarder · Gennemgået oktober 2026 · Af John Nielsen
En teknisk gennemgang af modpartens rapport skal svare på ét spørgsmål: Bærer data og metode de konklusioner, rapporten drager? Det afgøres ikke ved at læse konklusionen og vurdere, om den lyder rimelig, men ved at følge hvert væsentligt fund tilbage til kilden, kontrollere integritet, tid og fortolkning og lede efter de forklaringer, rapporten ikke har behandlet. Advokatens læsning af en rapport er beskrevet i Sådan læser du en IT-sagkyndig rapport, og ledelsens i Hvad får I ud af en IT-undersøgelse. Denne tjekliste er den tekniske gennemgang, som en sagkyndig eller en teknisk stærk læser udfører.
Før du begynder: skaf grundlaget
En rapport alene er sjældent nok. Bed, gennem advokaten, om:
- alle bilag i det format, de er udarbejdet i, fx regneark frem for PDF,
- hashlister for sikrede medier, images og eksporter,
- oplysning om værktøjer og versioner, hvis det ikke fremgår,
- de rå logudtræk eller artefakter, centrale fund bygger på,
- om muligt adgang til kopier af de sikrede data.
Notér, hvad du har modtaget, hvornår og i hvilken form. Din gennemgang er selv et forensisk arbejde, og din dokumentation skal kunne tåle samme kritik som den, du vurderer.
1. Materiale og integritet
- Er alle undersøgte kilder entydigt identificeret med serienummer, kontonavn eller bevisnummer?
- Er der hashværdier for hver sikring, og er algoritmen angivet?
- Hvad dækker hashværdien: hele mediet, et logisk image, en eksport eller enkelte filer?
- Er hashværdien kontrolleret efter overførsel og før analysen?
- Stemmer hashværdierne i rapporten med dem i bilagene?
En manglende eller uforklaret afvigende hashværdi er ikke i sig selv bevis for ændring, men den skal forklares. → Når hashværdien ikke stemmer
2. Sikringsmetode
- Er der tale om fysisk, logisk eller målrettet sikring, og er valget begrundet?
- Er data sikret af den sagkyndige, eller har parten selv eksporteret dem?
- Er sikringen foretaget før eller efter hændelser, der kan have ændret data, fx reinstallation, fratræden eller nulstilling af adgangskoder?
- Er der arbejdet på et tændt system, og er de handlinger, der blev udført, beskrevet?
- Er det beskrevet, hvilke data der ikke kunne sikres, og hvorfor?
En målrettet sikring kan være fuldt forsvarlig, men den begrænser, hvad rapporten kan udtale sig om. Fravær af spor i en målrettet indsamling betyder ikke fravær på enheden.
3. Værktøjer og versioner
- Er alle værktøjer nævnt med version?
- Er centrale fund kontrolleret manuelt eller med et andet værktøj?
- Findes der kendte fejl eller begrænsninger i den pågældende version for det relevante artefakt? Slå op i leverandørens release notes og fejllister for netop den version, og i offentlige testrapporter, hvor de findes.
- Bygger fundene på et værktøjs tolkning af et felt, som ikke er forklaret, fx kolonner som “Last Accessed” eller “Entry Modified”?
Kontrollér også, om værktøjets resultat er gengivet korrekt i rapporten. Afskrivningsfejl i stier, tidspunkter og hashværdier mellem bilag og tekst er almindelige, og de er lette at påvise. En enkelt fejl af den art behøver ikke ændre konklusionen, men flere af dem rejser spørgsmålet om, hvor grundig kontrollen før aflevering har været.
4. Tid
- Er tidszonen angivet for hver kilde og for rapporten som helhed?
- Er kilder i lokal tid, fx FAT-formaterede USB-drev og visse logs, normaliseret korrekt?
- Ligger centrale hændelser tæt på et skift mellem sommer- og vintertid?
- Er enhedernes ur kontrolleret mod en pålidelig kilde, og er en urafvigelse håndteret?
- Er rækkefølgen af hændelser fra forskellige kilder robust over for forskelle i opløsning og ur?
Tidsfejl er den hyppigste enkeltfejl i forensiske rapporter og kan vende en rækkefølge. → Sommertid og tidszoner i rapporten
5. Fortolkning af artefakter
Her ligger de fleste væsentlige svagheder. Kontrollér for hvert centralt fund:
- Hvad viser artefaktet faktisk? En LNK-fil viser typisk, at en fil er åbnet fra en placering, ikke at den er kopieret dertil.
- Kan artefaktet opstå automatisk, fx ved synkronisering, indeksering, antivirus eller backup?
- Er hændelser i en cloudlog forskel på synkronisering fra en klient og en brugers aktive handling?
- Bygger konklusionen om en person på et fund, der kun viser en konto eller en enhed?
6. Fravær og afgrænsning
- Står der “intet fundet” om noget, der reelt ikke er undersøgt?
- Dækker de undersøgte logs hele den relevante periode, eller er de roteret eller udløbet?
- Er der kilder, som sagens oplysninger peger på, men som ikke er med, fx en privat telefon, en delt postkasse eller en cloudtjeneste?
7. Alternative forklaringer
Skriv selv de oplagte alternative forklaringer ned, før du læser rapportens afsnit om dem. Sammenlign derefter. Er de behandlet? Er de afvist med en begrundelse, der bygger på data, eller blot nævnt? En rapport, der ikke forholder sig til en nærliggende forklaring, har en åbning, og det er ofte det vigtigste punkt i gennemgangen.
8. Konklusioner og sikkerhed
- Er der en defineret skala for sikkerhed, og bruges den konsekvent?
- Går konklusionen fra aktivitetsniveau til personniveau uden selvstændigt grundlag?
- Er formuleringerne om sandsynlighed vendt rigtigt, så de handler om fundene givet en forklaring og ikke omvendt?
- Indeholder rapporten juridiske vurderinger, som ligger uden for det tekniske?
→ Konklusionsgrader: verbale skalaer og likelihood ratio
9. Efterprøvning
Har du adgang til data, så gentag de fund, konklusionen hviler på: samme artefakt, samme post, gerne med et andet værktøj. Notér resultatet, også når det bekræfter rapporten. En gennemgang, der kun finder svagheder, er mindre troværdig end en, der også siger, hvad der holder.
10. Bilag, tabeller og tidslinjer
- Kan hvert fund i teksten findes i et bilag, og kan hvert bilag føres tilbage til en sikring?
- Er tidslinjer udvalgt, og er udvælgelseskriterierne oplyst?
- Er der hændelser i de rå data, som er udeladt af tidslinjen, men som taler imod konklusionen?
- Er skalaen på grafer og tidslinjer retvisende, eller ser hændelser, der ligger dage fra hinanden, ud til at ligge tæt?
- Er skærmbilleder fra analyseværktøjer suppleret med en beskrivelse af, hvor de underliggende data ligger?
Din egen rolle
Gennemgår du en rapport for den ene part, er du rådgiver for den part, ikke skønsmand. Det ændrer ikke kravet om faglig redelighed: Bemærkninger, der ikke kan begrundes teknisk, svækker gennemgangen og i sidste ende partens sag. Behandl materialet fortroligt, brug det kun til formålet, og notér, hvad du har haft adgang til. Har du tidligere haft en rolle i sagen, eller har du forbindelse til modpartens sagkyndige, skal det afklares, før du går i gang.
Sådan skrives resultatet
Klassificér hver bemærkning, så advokaten kan prioritere:
- Fejl · Fundet eller konklusionen er teknisk forkert
- Manglende grundlag · Konklusionen kan være rigtig, men data eller metode bærer den ikke
- Uafklaret · Oplysninger mangler for at kunne vurdere punktet
- Alternativ forklaring · En nærliggende forklaring er ikke behandlet
- Holder · Fundet er kontrolleret og bekræftet
Skriv om metoden og data, aldrig om personen bag rapporten. Hold dig til det tekniske, og lad advokaten vurdere, hvordan bemærkningerne skal bruges, fx i supplerende spørgsmål, en anmodning om data eller en egen erklæring. Hvordan en uvildig gennemgang kan bestilles, er beskrevet under second opinion på en IR- eller forensic-rapport.
Kilder og versioner
- NIST: Computer Forensics Tool Testing Program (CFTT), offentlige testrapporter for værktøjer
- ENFSI-BPM-FIT-01, bilag G.3 om gennemgang af rapporter, PDF
- ISO/IEC 27041:2015, egnethed og validering af metoder
- ISO/IEC 27042:2015, analyse og fortolkning af digitale beviser
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Kvalitet og standarder
Læs også: Konklusionsgrader: verbale skalaer og likelihood ratio · Besvarelse af skønstemaer: den tekniske struktur
→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
