Opsio - Cloud and AI Solutions
5 min read· 1,153 words

NIS2 hendelsesrapportering: 24 timer, 72 timer og sluttrapport

Publisert: ·Oppdatert: ·Gjennomgått av Opsios ingeniørteam
Oversatt fra engelsk og gjennomgått av Opsios redaksjon. Se originalen →
Fredrik Karlsson

Group COO & CISO

Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments

NIS2 hendelsesrapportering: 24 timer, 72 timer og sluttrapport

NIS2 hendelsesrapportering: 24 timer, 72 timer og sluttrapport

NIS2 innfører det strengeste hendelsesrapporteringsregimet i europeisk cybersikkerhetslovgivning. Tre trinn, tre frister, tre rapporter. Tidlig varsel innen 24 timer, oppdatering innen 72 timer og sluttrapport innen én måned. For mange virksomheter er dette en betydelig skjerping fra dagens praksis.

Ifølge ENISAs rapport om hendelsesrapportering under NIS1 overholdt bare 48 % av virksomheter den daværende rapporteringsfristen (ENISA, 2024). Med NIS2s strammere frister blir utfordringen enda større. Virksomheter som ikke har automatiserte deteksjons- og rapporteringsprosesser, vil slite.

Nøkkelpunkter
- Bare 48 % av NIS1-virksomheter overholdt rapporteringsfristen (ENISA, 2024)
- NIS2 krever tidlig varsel innen 24 timer, oppdatering innen 72 timer og sluttrapport innen 1 måned
- Rapporteringen går til CSIRT eller kompetent myndighet (sektormyndigheten)
- Dobbel rapporteringsplikt med GDPR ved persondata-hendelser

Hva utgjør en rapporteringspliktig hendelse?

NIS2 artikkel 23 definerer en «vesentlig hendelse» som en hendelse som har forårsaket eller kan forårsake alvorlige driftsforstyrrelser eller økonomiske tap, eller som har påvirket eller kan påvirke andre personer ved å forårsake betydelig skade (EU-kommisjonen, 2023). EU-kommisjonens gjennomføringsforordning gir mer detaljerte terskelverdier.

Kriterier for vesentlig hendelse

En hendelse er rapporteringspliktig dersom den forstyrrer eller kan forstyrre leveransen av kritiske tjenester, påvirker tilgjengeligheten, integriteten eller konfidensialiteten til data eller systemer, berører et betydelig antall brukere eller mottakere av tjenesten, eller forårsaker eller kan forårsake vesentlig økonomisk tap.

Eksempler på rapporteringspliktige hendelser

Ransomware-angrep som krypterer produksjonssystemer. DDoS-angrep som tar ned kundevendte tjenester i mer enn en definert periode. Datalekkasje som eksponerer sensitive data. Kompromittering av leverandør som påvirker virksomhetens systemer. Vesentlige konfigurasjonsfeil som eksponerer systemer.

Eksempler på hendelser som trolig ikke er rapporteringspliktige

Mislykket phishing-forsøk som stoppes av e-postfilter. Enkeltvis malware-infeksjon som isoleres raskt uten spredning. Kortvarig tjenesteavbrudd uten betydelig konsekvens.

Citatkapsel: NIS2 artikkel 23 definerer rapporteringspliktige hendelser som de som forårsaker alvorlige driftsforstyrrelser eller økonomiske tap, og bare 48 % av NIS1-virksomheter overholdt rapporteringsfristen (ENISA, 2024).

Hva er de tre rapporteringsfasene?

Rapporteringsprosessen har tre obligatoriske faser med distinkte frister og innholdskrav. Ifølge artikkel 23 i NIS2 er fristene absolutte, ikke veiledende (EU-kommisjonen, 2023). Manglende overholdelse kan i seg selv utløse sanksjoner.

Fase 1: Tidlig varsel (24 timer)

Frist: Innen 24 timer etter at virksomheten blir «oppmerksom på» hendelsen.

Innhold: Bekreftelse på at en vesentlig hendelse har funnet sted. Foreløpig vurdering av om hendelsen kan skyldes en ondsinnet handling. Om hendelsen kan ha grensekryssende konsekvenser.

Formål: Gi myndighetene tidlig varsling slik at de kan koordinere respons og varsle andre berørte.

Fase 2: Hendelsesvarsel/oppdatering (72 timer)

Frist: Innen 72 timer etter at virksomheten ble oppmerksom på hendelsen.

Innhold: Oppdatert vurdering av hendelsen, alvorlighetsgrad og konsekvenser. Indikatorer på kompromittering (IoC) der tilgjengelig. Initielle tiltak iverksatt for å håndtere og begrense hendelsen.

Formål: Gi myndighetene tilstrekkelig informasjon til å vurdere hendelsens omfang og koordinere ytterligere.

Fase 3: Sluttrapport (1 måned)

Frist: Senest 1 måned etter hendelsesvarsel (fase 2).

Innhold: Detaljert beskrivelse av hendelsen. Rot-årsaksanalyse. Tiltak iverksatt og planlagt. Grensekryssende konsekvenser der relevant.

Formål: Dokumentere hendelsen for læring, statistikk og tilsynsformål.

Tillegg: Mellomrapport

Dersom hendelsen fortsatt pågår etter 1 måned, krever NIS2 en mellomrapport (status update) på dette tidspunktet, med endelig sluttrapport innen 1 måned etter at hendelsen er løst.

Gratis eksperthjelp

Trenger dere eksperthjelp med nis2 hendelsesrapportering?

Våre skyarkitekter hjelper dere med nis2 hendelsesrapportering — fra strategi til implementering. Book et gratis 30-minutters rådgivningssamtale uten forpliktelse.

Solution ArchitectAI-spesialistSikkerhetsekspertDevOps-ingeniør
50+ sertifiserte ingeniørerAWS Advanced Partner24/7 support
Helt gratis — ingen forpliktelseSvar innen 24t

Hvem skal rapporten sendes til?

NIS2 artikkel 23 gir virksomheter valget mellom å rapportere til CSIRT eller direkte til kompetent myndighet (EU-kommisjonen, 2023). I norsk kontekst vil det bety NorCERT (under NSM) og/eller sektormyndigheten.

NorCERT/NSM

NorCERT er Norges nasjonale CSIRT og den naturlige mottakeren av hendelsesrapporter. NorCERT har eksisterende systemer og prosesser for å håndtere henvendelser fra virksomheter.

Sektormyndigheten

Avhengig av digitalsikkerhetslovens utforming kan rapportering gå direkte til sektormyndigheten (NVE for energi, Finanstilsynet for finans, etc.) eller via NorCERT.

Parallell GDPR-rapportering

Dersom hendelsen involverer persondata, skal Datatilsynet også varsles innen 72 timer under GDPR artikkel 33. Merk at NIS2-fristen for tidlig varsel er 24 timer, altså strammere enn GDPRs 72 timer. Etabler én prosess som dekker begge frister.

[UNIQUE INSIGHT] Et praktisk problem som mange overser: hvem er «virksomheten» når det gjelder «oppmerksom på»? Klokkene begynner å tikke når virksomheten (ikke nødvendigvis IT-avdelingen) blir oppmerksom på hendelsen. Definer tydelig hvem i organisasjonen som har myndighet til å erklære en hendelse som rapporteringspliktig. Uklare ansvarslinjer fører til forsinkelser.

Hvordan bygger du en effektiv rapporteringsprosess?

Ifølge IBM Security er gjennomsnittlig tid for å oppdage et datainnbrudd 194 dager (IBM, 2024). NIS2 krever rapportering innen 24 timer etter oppdagelse. Deteksjonsevne er derfor en forutsetning for å overholde rapporteringskravene.

Forbedre deteksjonsevnen

Implementer SIEM (Security Information and Event Management) eller tilsvarende for sentralisert logging og korrelering. Bruk automatiserte varsler for mistenkelige aktiviteter. Vurder SOC-tjenester (Security Operations Center) for 24/7-overvåking.

Etabler intern eskaleringsrutine

Definer klare kriterier for når en hendelse er rapporteringspliktig. Etabler en eskaleringsmatrise: hvem varsles internt, i hvilken rekkefølge, og hvem har myndighet til å sende ekstern rapport. Test rutinen gjennom øvelser.

Klargjør rapporteringsmaler

Ha ferdigutfylte maler for 24-timers varsel, 72-timers oppdatering og sluttrapport. Jo mer som er forberedt på forhånd, jo raskere kan du rapportere under press.

Øv regelmessig

Gjennomfør hendelsesøvelser som tester hele kjeden fra deteksjon til rapportering. Inkluder ledelsen i øvelsene, ettersom de har godkjenningsansvar. Mål tiden fra simulert hendelse til ferdig rapport.

[PERSONAL EXPERIENCE] I hendelsesøvelser vi har fasilitert for nordiske virksomheter, bruker flertallet over 24 timer bare på intern koordinering før de er klare til å sende første rapport. Den viktigste forbedringen er å forenkle den interne prosessen: færre godkjenningstrinn, forhåndsdefinerte maler og tydelig eskaleringsmatrise.

Ofte stilte spørsmål

Hva om vi ikke har full oversikt etter 24 timer?

Send tidlig varsel likevel. NIS2 artikkel 23 krever ikke fullstendig informasjon i det tidlige varselet. En bekreftelse på at en hendelse har funnet sted, en foreløpig vurdering og en indikasjon på grensekryssende konsekvenser er tilstrekkelig.

Starter 24-timersfristen fra hendelsestidspunktet eller oppdagelsestidspunktet?

Fra oppdagelsestidspunktet, definert som når virksomheten blir «oppmerksom på» hendelsen. Dersom en hendelse skjedde for tre dager siden men oppdages i dag, starter 24-timersfristen i dag.

Hva om hendelsen viser seg å ikke være vesentlig?

Bedre å rapportere for mye enn for lite. Dersom en rapportert hendelse viser seg å være mindre alvorlig, kan dette avklares i sluttrapport. Det er ingen sanksjon for å rapportere hendelser som viser seg å ikke være vesentlige.

Gjelder rapporteringsfristen også i helger og ferier?

Ja, 24-timersfristen er absolutt og gjelder uavhengig av tidspunkt. Virksomheter må ha prosesser som fungerer 24/7, eventuelt gjennom vaktordninger eller outsourcede SOC-tjenester.

Kan vi rapportere via e-post?

Den endelige rapporteringsmekanismen i Norge vil avhenge av digitalsikkerhetsloven og tilhørende forskrifter. I noen EU-land er det etablert dedikerte portaler. I mellomtiden er NorCERTs eksisterende rapporteringskanaler det naturlige kontaktpunktet.

Viktige punkter om NIS2 hendelsesrapportering 24 timer 72

NIS2s hendelsesrapporteringskrav er krevende men gjennomførbare med god forberedelse. Nøklene er deteksjonsevne, forhåndsdefinerte prosesser, øvelser og klare ansvarslinjer. Ikke vent til en hendelse inntreffer med å bygge rapporteringsprosessen. Gjør det nå, og test den regelmessig.


Meta description: NIS2 krever hendelsesrapportering innen 24 timer. Bare 48 % overholdt fristen under NIS1. Lær de tre fasene og bygg effektive prosesser.

Om forfatteren

Fredrik Karlsson
Fredrik Karlsson

Group COO & CISO at Opsio

Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments

Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.