Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
NIS2-direktivet indfører en trinvis indberetning af væsentlige hændelser: en tidlig varsling, en hændelsesrapport og en endelig rapport, hver med sin frist og sit indhold. For den tekniske organisation betyder det, at bestemte fakta skal kunne leveres inden for bestemte tidsrum, og at de skal bygge på kilder, der kan efterprøves senere. Det kræver, at logkilderne er kendt, sikret og koblet til de spørgsmål, hvert trin stiller, før hændelsen sker.
Den organisatoriske side, med logbog, roller og vurdering af, om hændelsen er væsentlig, er beskrevet i NIS2: dokumentation, når hændelsen er sket. Her handler det om de tekniske kilder bag indberetningen.
Trinene og deres tekniske spørgsmål
Direktivets artikel 23 beskriver tre trin. Fristerne for varsling og hændelsesrapport regnes fra det tidspunkt, hvor enheden fik kendskab til den væsentlige hændelse. I Danmark er direktivet gennemført ved NIS2-loven fra 2025, og indberetningen sker som udgangspunkt via virk.dk. Sektorregler kan stille yderligere krav, og den juridiske vurdering af, hvad der gælder for den enkelte virksomhed, hører under rådgiverne, se også Cyberangreb: tvisten med IT-leverandøren.
- Tidlig varsling · Typisk frist i direktivet: Inden for 24 timer · Teknisk kerne: Mistanke om ondsindet handling, mulig grænseoverskridende virkning
- Hændelsesrapport · Typisk frist i direktivet: Inden for 72 timer · Teknisk kerne: Første vurdering af alvor og virkning, indikatorer
- Endelig rapport · Typisk frist i direktivet: Inden for en måned efter hændelsesrapporten · Teknisk kerne: Detaljeret beskrivelse, årsag, afhjælpning
Derudover kan myndigheden bede om mellemliggende statusrapporter, og hvis hændelsen stadig er i gang efter en måned, skal der i stedet gives en statusrapport.
Tidlig varsling: er det ondsindet?
Spørgsmålet om, hvorvidt hændelsen mistænkes at skyldes en ulovlig eller ondsindet handling, er teknisk. Det besvares typisk ud fra EDR-detektioner, kendte ondsindede filer, logins fra ukendte adresser eller uautoriserede ændringer. På 24 timer er det ofte en mistanke, ikke en konklusion, og det skal skrives sådan. Notér, hvilke konkrete observationer mistanken bygger på, og hvor de stammer fra.
Grænseoverskridende virkning kan vurderes ud fra, hvilke systemer og tjenester der er ramt, og hvem der bruger dem: kunder i andre lande, integrationer med udenlandske partnere eller fælles platforme.
Hændelsesrapport: alvor, virkning og indikatorer
Efter 72 timer forventes en første vurdering af hændelsens alvor og virkning og, hvor de findes, kompromitteringsindikatorer. De tekniske kilder er:
- Overvågning og driftsdata for virkningen: hvilke tjenester faldt ud, hvornår og hvor længe.
- EDR, SIEM og netværkslogs for omfanget: hvilke systemer og konti er berørt.
- Indikatorer fra analysen: hashværdier, IP-adresser, domæner, kontonavne og filnavne.
Indikatorer skal deles med omtanke. De kan indeholde interne oplysninger, og de bør være kvalitetssikret, så der ikke sendes legitime adresser videre som ondsindede.
Endelig rapport: årsag og afhjælpning
Den endelige rapport skal blandt andet beskrive hændelsen i detaljer, typen af trussel eller den grundlæggende årsag, de iværksatte afhjælpende foranstaltninger og en eventuel grænseoverskridende virkning. Det er her, analysen af indgangsvej og forløb kommer i spil. Se Indgangsvejen: sådan underbygges konklusionen. Er analysen ikke afsluttet, skal rapporten sige, hvad der er kendt, og hvad der stadig undersøges.
Logkilderne, der skal være klar
NIS2 stiller krav om risikostyring, herunder om hændelseshåndtering og logning. I praksis betyder det, at de kilder, indberetningen bygger på, skal være på plads, før hændelsen sker:
- Centraliseret logning fra identitet, endpoints, netværk og vigtige applikationer, med en opbevaringstid, der rækker længere end den tid, det tager at opdage en hændelse. Se SIEM-data som bevis.
- Driftsdata fra overvågning, der kan vise tilgængelighed over tid.
- Konfigurationshistorik for centrale systemer, så ændringer kan dateres.
- Tidssynkronisering på tværs af systemer, så tidslinjen hænger sammen.
Hvilket minimum af logning virksomheden bør have, er beskrevet fra ledelsens side i Minimumslogning.
Logs hos leverandører
En stor del af de relevante logs ligger ofte hos leverandører: driftsleverandøren, SaaS-udbydere, cloudplatforme og leverandører af sikkerhedsovervågning. NIS2 lægger vægt på sikkerhed i forsyningskæden, og det gælder også adgangen til data efter en hændelse. Afklar på forhånd, hvilke logs hver leverandør har, hvor længe de opbevares, i hvilket format de kan udleveres, og hvor hurtigt. En leverandør, der først kan levere logs efter en uge, gør det svært at nå en hændelsesrapport på 72 timer med et solidt grundlag.
Når logs modtages fra en leverandør, så registrér, hvornår og hvordan de blev modtaget, beregn en hashværdi ved modtagelsen, og notér, om leverandøren selv har filtreret eller bearbejdet dem. Det er især vigtigt, hvis leverandørens egne systemer kan være en del af hændelsen.
Statusrapporter undervejs
Ved længerevarende hændelser kan myndigheden bede om statusopdateringer. Hver opdatering bør bygge på en dateret version af tidslinjen og faktaarket, så det senere kan ses, hvad der var kendt på hvert tidspunkt. Det gør det også lettere at forklare, hvorfor en tidlig vurdering blev justeret.
Integritet og efterprøvelighed
Myndigheden kan stille opfølgende spørgsmål, og indberetningen kan senere indgå i et tilsyn eller en tvist. Det, der står i rapporterne, skal derfor kunne føres tilbage til data, der ikke er ændret siden. Eksportér de logs, en rapport bygger på, med hashværdi og tidspunkt, og opbevar dem sammen med rapporten. Er loggene i et system, som en kompromitteret administratorkonto kunne ændre, skal det fremgå, og der bør søges uafhængige kilder. Se Logintegritet.
Tidspunktet for kendskab
Fristerne løber fra kendskabstidspunktet. Det gør det vigtigt teknisk at kunne dokumentere, hvornår der forelå hvilke oplysninger: den første alarm, den første analyse, der pegede på en væsentlig hændelse, og beslutningen om at klassificere den som væsentlig. Alarmsystemets historik, tickets og hændelseslogbogen er kilderne. Hold dem adskilt fra spørgsmålet om, hvornår hændelsen begyndte, som er noget helt andet. Se Dwell time.
Persondata og NIS2 på samme tid
En hændelse, der berører persondata, kan skulle anmeldes både efter NIS2 og efter databeskyttelsesreglerne, med forskellige frister og til forskellige myndigheder. Det tekniske faktagrundlag bør bygges én gang og bruges til begge, med tydelige versioner, så de to indberetninger ikke kommer til at sige noget forskelligt om de samme fakta. Se Persondatabrud på 72 timer.
Typiske problemer
- Logopbevaringen er kortere end den tid, det tog at opdage hændelsen, så årsagen ikke kan fastlægges til den endelige rapport.
- Den tidlige varsling beskriver en mistanke som en konklusion, og den senere rapport må trække den tilbage.
- Indikatorer deles uden kvalitetssikring.
- Tidslinjer i de tre rapporter bygger på forskellige eksporter med forskellige tidszoner.
- Data til den endelige rapport er ikke sikret, fordi systemerne er genopsat.
Forbered rapportskabeloner
Det mest effektive forberedende arbejde er en teknisk skabelon for hvert trin, hvor hvert felt i indberetningen er koblet til den eller de logkilder, der besvarer det, og til den person, der henter dem. Så bliver de første 24 timer et spørgsmål om at udfylde, ikke om at finde ud af, hvor data ligger. Afprøv skabelonen ved en øvelse, hvor logs faktisk hentes og pakkes med hashværdier inden for den tid, fristen giver. Øvelsen afslører typisk huller i adgang, opbevaring og leverandøraftaler, som er langt nemmere at lukke i ro end under en hændelse.
Kilder og versioner
- EUR-Lex: NIS2-direktivet (EU) 2022/2555, artikel 23
- Retsinformation: lov nr. 434 af 6. maj 2025 (NIS2-loven)
- Virk.dk: vejledning i indberetning af hændelser efter NIS2
Senest gennemgået: oktober 2026.
Næste skridt
- Cyberforsikringen: de tekniske leverancer, forsikringsselskabet beder om
- Forsikringstvist: dokumentation af sikkerhedsniveauet før hændelsen
- Hvilke persondata blev berørt? Teknisk afgrænsning af et databrud
Del af: Undersøgelse efter et hackerangreb
Læs også: Hvilke persondata blev berørt? Teknisk afgrænsning af et databrud · Overdragelse fra IR-team til sagkyndig
→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
