Forside › Kvalitet og standarder · Gennemgået oktober 2026 · Af John Nielsen
I et IT-skøn bør skønsmanden arbejde på et datasæt, som begge parter kan kontrollere: en dokumenteret beviskopi med kendte hashværdier, et hashmanifest, der udleveres til begge sider, og en beskrivelse af, hvordan kopien er lavet. Når der er brug for adgang til kørende systemer, skal adgangen være aftalt, ske med navngivne konti og læserettigheder, være logget og foregå med begge parter orienteret. Så handler uenigheden om, hvad data viser, og ikke om, hvilke data der blev set på.
Den juridiske side af skønsmandens adgang er beskrevet på digital-bevissikring.dk. Hvordan selve skønstemaerne besvares teknisk, står i besvarelse af skønstemaer. Her er den tekniske side af datagrundlaget.
Hvorfor et fælles datasæt
Digitale data ændrer sig. En postkasse, et ticketsystem eller et udviklingsmiljø ser anderledes ud fra uge til uge. Har parterne og skønsmanden hver sin kopi, taget på forskellige tidspunkter med forskellige metoder, kan de nå forskellige resultater, uden at nogen har lavet fejl. Et fælles datasæt med en hashværdi, alle kender, fjerner den usikkerhed og gør hvert fund i skønserklæringen sporbart til et bestemt materiale. Det letter også afhjemlingen: spørgsmål om, hvorvidt skønsmanden har set de rigtige data, kan besvares med en henvisning til manifestet frem for med en forklaring.
Tre slags grundlag
Beviskopier sikret før skønnet. Den ene part har ofte allerede sikret data, fx ved hændelsen eller før stævning. Skønsmanden skal have dokumentationen for sikringen: metode, værktøj, tidspunkt, hashværdier og kæden af ansvar. Er originalmediet bevaret, kan skønsmanden kontrollere hashværdien mod det. Er det ikke, må det fremgå, at kopien er taget for pålydende på den dokumentation, der foreligger.
Ny sikring under skønsforretningen. Skønsmanden kan selv sikre data, typisk med parterne indkaldt. Fordelen er, at metoden er skønsmandens egen, og at begge parter har haft mulighed for at overvære den. Hvordan en fælles sikring kan tilrettelægges, er beskrevet i fælles sikring med modpartens sagkyndige.
Adgang til kørende systemer. Nogle spørgsmål kan kun besvares ved at se systemet i drift, fx funktionalitet i en IT-leverance. Her er det ikke muligt at hashe systemet som helhed, og dokumentationen skal derfor bygges på anden måde.
Samme kopi, samme hash
Når skønsmanden har en masterkopi, sker resten efter et fast mønster:
- Hashværdier beregnes for masterkopien og, ved filsamlinger, for hver fil i et hashmanifest.
- Manifestet udleveres til begge parter, før analysen begynder.
- Arbejdskopier dannes fra masterkopien og verificeres mod den. Kopi-hierarkiet er beskrevet i arbejdskopi og masterkopi.
- Kopier til parterne, hvis det er aftalt, dannes fra samme master og kontrolleres af modtageren med samme manifest.
- Skønserklæringen henviser til hashværdierne, så hvert fund kan føres tilbage til materialet.
Ved containerformater som E01 skal det stå, om hashværdien gælder de rå data i imaget eller containerfilerne. De to er forskellige, og forveksling er en hyppig kilde til unødig tvivl.
Når parterne har hver sin kopi
Har begge parter sikret det samme system på forskellige tidspunkter, kan manifesterne sammenlignes maskinelt. Forskellene falder typisk i tre grupper: filer, der kun findes i den ene kopi, filer med samme sti, men forskellig hashværdi, og filer, der er ens. De to første grupper skal forklares, ofte ved tidspunktet for sikringen eller ved forskellige filtre. Skønsmanden bør beskrive, hvilken kopi der er brugt til hvad, og hvorfor.
Adgang til kørende systemer
Når skønsmanden skal ind i et kørende system, bør adgangen opfylde disse krav:
- Navngiven konto til skønsmanden, ikke en delt konto eller en af parternes egne.
- Læserettigheder, medmindre en test kræver mere. Kræver den ændringer, udføres de i en kopi eller et testmiljø.
- Tidsbegrænsning og totrinsgodkendelse.
- Revisionslogning slået til i systemet, og loggen eksporteres efter besøget.
- Begge parter orienteret om tidspunkt og omfang, og eventuelt til stede.
- Dokumentation undervejs: skærmbilleder med tidspunkt, optagelse af sessionen og en log over handlinger.
Skal en funktion afprøves, kan miljøet sikres med et snapshot før og efter, så det kan vises, hvad afprøvningen ændrede. For IT-projekter er tilstanden af leverancen beskrevet i sikring af en leverances tilstand.
Fortrolige data i datasættet
Datasættet kan indeholde forretningshemmeligheder eller persondata, som den ene part ikke bør se. Teknisk kan det løses ved, at skønsmanden har den fulde masterkopi, mens parterne får afledte kopier med en dokumenteret filtrering. Filtreringen beskrives præcist, og de afledte kopier får deres egne manifester, der kan føres tilbage til masterens. Om og hvordan parterne får adgang, afgøres ikke teknisk.
Formater, som alle kan læse
Et fælles datasæt nytter kun, hvis begge parters sagkyndige kan åbne det. Vælg derfor åbne eller udbredte formater: rå images eller E01 for medier, oprindelige eksportformater som PST, EML, JSON eller CSV for cloud- og systemdata, og tekstbaserede manifester. Undgå, at materialet kun kan læses i ét bestemt kommercielt værktøj, medmindre begge parter har adgang til det. Er en del af data kun tilgængelig gennem et proprietært format, så beskriv det, og angiv, hvilke værktøjer og versioner der kan læse det.
Tidspunktet og skønstemaets periode
Skønstemaerne handler ofte om en tilstand på et bestemt tidspunkt: hvordan en leverance så ud ved overtagelsen, eller hvad der lå i et system på en bestemt dato. Et datasæt sikret senere viser tilstanden på sikringstidspunktet. Skønsmanden skal derfor beskrive afstanden mellem de to tidspunkter og vurdere, om ændringer i mellemtiden kan påvirke svaret. Versionshistorik, logs og backup fra det relevante tidspunkt kan bygge bro, men de skal sikres og dokumenteres på samme måde som resten.
Supplerende spørgsmål og overskøn
Kommer der supplerende spørgsmål eller et overskøn, er det en stor fordel, at datasættet allerede er fastlagt med hashværdier. Den nye skønsmand kan arbejde på samme materiale og kontrollere det mod manifestet uden en ny sikring. Det forudsætter, at masterkopien opbevares, indtil sagen er endeligt afsluttet, og at det er aftalt, hvem der opbevarer den.
Dokumentation i skønserklæringen
En skønserklæring bør i et teknisk afsnit angive:
- hvert datasæt med hashværdi, kilde, tidspunkt og hvem der sikrede det,
- hvem der var til stede ved sikring og besigtigelse,
- konti, rettigheder og tidspunkter for adgang til kørende systemer,
- eksporteret revisionslog fra adgangen,
- værktøjer og versioner,
- afvigelser, fx data der ikke kunne sikres eller manifester, der ikke stemte.
Typiske fejl
- Skønsmanden arbejder på et regneark eller en rapport, som en part har udarbejdet, uden adgang til kilden.
- Det kørende system ændres mellem besigtigelsen og erklæringen, og der er ingen kopi af tilstanden.
- Kopier til parterne laves fra forskellige kilder og har derfor forskellige hashværdier.
- Adgangen sker med en af parternes administratorkonti, så skønsmandens handlinger ikke kan skilles fra partens.
Kilder og versioner
- ISO/IEC 27037:2012: Guidelines for identification, collection, acquisition and preservation of digital evidence
- ISO/IEC 27042:2015: Guidelines for the analysis and interpretation of digital evidence
- NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Kvalitet og standarder
Læs også: Visualiseringer i forensiske rapporter: korrekte grafer og tidslinjer · Hvor lang tid tager en forensisk undersøgelse? Det afgør tidsforbruget
→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
