Cyberforsikringen: de tekniske leverancer, forsikringsselskabet beder om

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

Efter en cyberhændelse beder forsikringsselskabet typisk om fire tekniske leverancer: en tidslinje over forløbet, en vurdering af indgangsvej og rodårsag, en opgørelse af berørte systemer og data, og adgang til eller kopier af de underliggende logs og billeder. Det, der afgør, om leverancerne holder, er ikke mængden, men om de kan efterprøves: Hver påstand skal kunne føres tilbage til en kilde, og hver kilde skal være intakt og dokumenteret.

Hvad forsikringsselskabet spørger om set fra virksomheden og fra advokaten, står i Ransomware: hvad skal forsikringsselskabet have dokumenteret? og Forsikringssager efter cyberangreb. Her handler det om, hvordan de tekniske leverancer bygges og pakkes.

Leverancerne

Tidslinje · Hændelser med tidspunkt, tidszone, kilde og forklaring
Rodårsag og indgangsvej · Konklusion, evidensniveau og afprøvede alternativer
Omfang · Berørte systemer, konti og data, med afgrænsning
Rådata · Logeksporter, diskkopier, hukommelse, filprøver
Indgrebslog · Hvad forsvarerne gjorde, og hvornår
Sikkerhedsniveau før hændelsen · MFA, patchniveau, backup og logning

Den sidste leverance er ofte den, der bliver mest omdiskuteret, fordi den kan påvirke dækningen. Den er behandlet for sig i Forsikringstvist: sikkerhedsniveauet før hændelsen.

Tidslinjen

Tidslinjen er den leverance, alle andre hænger på. Den bør leveres i to former: en læsbar version i rapporten med de vigtigste hændelser, og en fuld version i et maskinlæsbart format, fx CSV, med én hændelse pr. linje. Hver linje skal have tidspunkt i UTC, den oprindelige tidszone, kildesystem, kildefil eller logtype, en henvisning til den konkrete post og en kort beskrivelse. Så kan forsikringsselskabets egen tekniske rådgiver kontrollere en tilfældig post mod rådata uden at skulle spørge.

Normaliseringen af tidszoner og felter er en kilde til fejl, især når logs fra mange systemer samles. Beskriv, hvordan det er gjort: hvilke kilder der var i lokal tid, hvordan sommertid er håndteret, og hvilke felter der er omdøbt eller slået sammen. Behold de oprindelige værdier i separate kolonner, så konverteringen kan kontrolleres.

Rodårsag og indgangsvej

Forsikringsselskabet vil vide, hvordan angriberen kom ind, og om det skyldtes et forhold, der er omfattet af policens krav. Leverancen skal angive konklusionen, hvor sikker den er, og hvilke alternative indgange der er undersøgt og med hvilket resultat. En konklusion uden evidensniveau og uden afprøvede alternativer er sårbar, uanset om den er rigtig. Fremgangsmåden er beskrevet i Indgangsvejen: sådan underbygges konklusionen.

Omfang

Opgørelsen af berørte systemer bør skelne mellem systemer, hvor der er spor efter angriberens aktivitet, systemer, der blev krypteret, og systemer, der blev isoleret eller genopsat som forholdsregel. Den sidste gruppe er relevant for omkostningerne, men må ikke blandes sammen med de kompromitterede. For data skelnes på samme måde mellem det, der med sikkerhed er tilgået eller hentet, det, der sandsynligvis er, og det, angriberen havde adgang til.

Rådata

Format

Lever rådata i formater, der kan læses af almindelige værktøjer og ikke kræver adgang til virksomhedens egne systemer:

Diskkopier i et anerkendt forensisk format med indbygget eller ledsagende hashværdi. Se Forensiske diskformater.
Logs i det oprindelige eksportformat, fx EVTX for Windows-hændelseslogs og JSON eller CSV for cloudlogs, ikke som skærmbilleder eller PDF.
Hukommelsesbilleder i rå form med angivelse af værktøj og version.
Filprøver, fx løsesumsbeskeder og ondsindede filer, i et beskyttet arkiv med tydelig markering.

Manifest

Pak rådata med et manifest: en liste over alle filer med sti, størrelse, hashværdi, kilde, tidspunkt for sikring og den person, der sikrede. Manifestet bør selv hashes og registreres. Det gør det muligt for modtageren at kontrollere, at alt er modtaget uændret, og for afsenderen at vise, hvad der er leveret. Se Hashmanifest for filsamlinger.

Beskrivelse

Læg en kort beskrivelse ved hver kilde: hvad den er, hvilken periode den dækker, om den er fuldstændig, og eventuelle kendte huller. Det sparer mange spørgsmål og forhindrer, at et hul fortolkes som stilhed.

Fortrolighed og persondata

Rådata indeholder næsten altid persondata: mails, filnavne, brugernavne og IP-adresser. Lever kun det, der er nødvendigt for formålet, og aftal med modtageren, hvordan data opbevares og slettes. Hvor det er muligt, kan rapportbilag pseudonymiseres, mens rådata stilles til rådighed på forespørgsel. Pseudonymiseringen skal være konsekvent, så samme person eller konto har samme pseudonym i hele materialet, og nøglen opbevares adskilt. Overførsel bør ske krypteret, med adgangskoden sendt ad en anden kanal, og modtagelsen bør kvitteres.

Omkostningsdata med teknisk grundlag

Virksomheden skal også dokumentere omkostningerne over for forsikringsselskabet, og mange af dem har et teknisk grundlag: timer brugt på genopretning, systemer genopsat, licenser og hardware købt til erstatning, og den periode, hvor systemerne var nede. Den tekniske dokumentation kan understøtte opgørelsen ved at vise, hvornår hvert system faldt ud og kom tilbage, fx fra overvågningsdata, og hvilke indgreb der var nødvendige for hvert system, fra indgrebsloggen. Hold de tekniske data adskilt fra selve opgørelsen af beløb, så det er tydeligt, hvad der er målt, og hvad der er beregnet.

Genbrug til andre formål

Den samme dokumentation bruges ofte også til Datatilsynet, kunder, en eventuel tvist med IT-leverandøren og en senere skønsforretning. Byg derfor leverancerne, så de ikke er skrevet til ét formål. Hold fakta adskilt fra vurderinger, og hold vurderingerne adskilt fra anbefalinger. En rapport, der blander tekniske fund med forslag til forbedringer, kan blive læst som en indrømmelse af mangler, der ikke er påvist.

Typiske problemer

Rapporten fra IR-leverandøren mangler kildehenvisninger og kan ikke efterprøves. Se IR-rapporten som bevis for, hvad der typisk mangler.
Logs er eksporteret med et filter, som ikke er dokumenteret, så det er uklart, hvad der er udeladt.
Tidslinjen blander tidszoner uden at sige det.
Rådata leveres uden hashværdier, eller hashværdierne er beregnet først ved afsendelsen og ikke ved sikringen.
Forsikringsselskabets rådgiver og virksomhedens egen leverandør har forskellige versioner af de samme data.
Der leveres løbende delresultater uden versionsnummer, så det senere er uklart, hvilken version en konklusion byggede på. Giv hver leverance en dato og et versionsnummer, og notér ændringer.

Når forsikringsselskabet selv undersøger

Nogle policer giver forsikringsselskabet ret til at udpege eller godkende den, der undersøger hændelsen. Så er det afgørende at afklare tidligt, hvem der ejer data og rapporter, og om virksomheden får adgang til rådata og arbejdsnoter. Uden dem kan virksomheden ikke selv efterprøve konklusionerne, hvis der opstår uenighed om dækningen. Aftal det skriftligt, før arbejdet går i gang, og notér i indgrebsloggen, hvilke data der overdrages til hvem.

Hvad leverancerne kan bære

Velbyggede leverancer kan bære en afgørelse om dækning, fordi de gør det muligt for flere parter at nå frem til den samme forståelse af fakta, eller i det mindste at se præcist, hvor de er uenige. Det er målet: ikke at overbevise, men at gøre det muligt at efterprøve.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Dwell time: hvornår kom angriberen ind? · Forsikringstvist: dokumentation af sikkerhedsniveauet før hændelsen

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For MSP’er · 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