20. oktober 2025

NIS2: Hvad betyder "væsentlig hændelse" i praksis?

Kort version: En “væsentlig hændelse” under NIS2 er en sikkerhedshændelse, der i væsentlig grad påvirker de systemer, som bruges til at levere jeres tjeneste som væsentlig eller vigtig enhed. Det, der tæller, er konsekvensen: driftsforstyrrelser, økonomisk tab eller betydelig skade for andre - samt forplantningseffekter i jeres leverandørkæde. Rapportering og tærskler er nationalt fastsat; processen skal være dokumenteret og gentagelig.



Hvad dækker begrebet "væsentlig hændelse"?


En hændelse anses for væsentlig, hvis én af følgende er opfyldt:


  • Den har forårsaget - eller kan forårsage - alvorlige driftsforstyrrelser af jeres tjeneste eller økonomisk tab for enheden.

  • Den har påvirket - eller kan påvirke - andre ved at forårsage betydelig fysisk eller ikke-fysisk skade (fx. betydelig materiel eller immateriel skade).


NIS2 lægger desuden vægt på styrket styring, leverandørkædesikkerhed og skærpede krav på tværs af flere sektorer - alt sammen for at hæve det fælles sikkerhedsniveau og ensrette rapportering. Det betyder, at flere organisationer end før skal kunne vurdere, dokumentere og rapportere hændelser konsekvent.


Scope: Vurderingen angår den tjeneste, I leverer som væsentlig/vigtig enhed. En intern hændelse uden effekt på tjenesten er typisk ikke en NIS2-væsentlig hændelse - men skal stadig behandles i jeres interne beredskab.



5 typiske cases


1) IT drift: Platform nede i arbejdstid


  • Situation: 90 min. nedetid på kernefunktioner kl. 10-11.30; ~25-30% af aktive brugere ramt.

  • Vurdering: Ofte væsentlig pga. kombinationen af omfang, varighed, og direkte servicepåvirkning.

  • Tiltag: Eskalér hændelsesteam, informer berørte kunder, dokumentér SLA-afvigelse, udføre RCA og opdater kontroller. (Rapporter efter national vejledning og jeres politik).



2) Leverandørfejl: Underdatabehandler ændrer datalokalitet


  • Situation: Tjenestekritisk underleverandør flytter behandling til nyt land. Ingen nedetid, men ændret retsligt grundlag.

  • Vurdering: Kan være væsentlig afhængigt af kontrakter, compliance og kædeeffekt.

  • Tiltag: Indhent detaljer, vurder TIA-behov, opdatér DPA/bilag, informer kunder efter politik. (NIS2 udvider fokus på leverandørkæden).



3) Databrud: Fejl i adgangsstyring (RBAC)


  • Situation: For brede rettigheder i 20 timer i et system, der understøtter tjenesten. Ingen dokumenteret misbrug, men potentiel adgang til data.

  • Vurdering: Mistanke om væsentlig - afhænger af datatyper, systemkritikalitet og tegn på misbrug.

  • Tiltag: Luk hullet, gennemgå logs, vurder berørte konti/systemer, dokumentér beslutning og kommunikation, og følg nationale indberetningskrav.



4) DoS/DDoS: Kortvarig påvirkning med mitigering


  • Situation: 20 minutters DDoS mod tjenestens frontend; mitigering virker; ingen datatab.

  • Vurdering: Typisk ikke væsentlig, men log og læring stadig vigtig.

  • Tiltag: Dokumentér indikatorer, respons, forbedringer og opdater runbooks i jeres GRC.



5) Fysisk nedbrud: Strøm/klima påvirker backup


  • Situation: Datacenterfejl overskrider tjenestens RPO/RTO; enkelte kunder mister op til 24 timers ændringer.

  • Vurdering: Ofte væsentlig pga. brud på integritet/tilgængelighed og indgåede løfter.

  • Tiltag: Eskalér, informer berørte kunder, justér backup-test og beredskab; luk sagen med RCA og forbedringer.



Hvem vurderer - og hvad vægtes?


Hold vurderingen lille, navngivet og målbar:


Roller

  • Hændelsesleder: Ejer triage, klassificering og koordinering.

  • Teknisk ansvarlig: Fakta, inddæmning, gendannelse, evidens.

  • Compliance/InfoSec: Væsentlighed iht. NIS2-scope, dokumentation og rapportering.

  • Kunde/kommunikation: Klar, rettidig besked til berørte kunder.

  • Ledelse: Godkender ved væsentlighed/rapportering.


Vigtige vægte

  • Omfang & varighed (især i arbejdstid/peak)

  • Kritikalitet & SLA for den leverede tjeneste.

  • Datatyper (følsomme data, legitimationsoplysninger, nøgler).

  • Kædeeffekt (leverandører/underdatabehandlere/kunder).

  • Genopretning (workaround, normalisering).


NIS2 skærper governance og krav till risikostyring/leverandørstyring, hvilket taler for foruddefinerede tærskler og faste roller.



Hvordan dokumenterer du beslutningen i et GRC-system?


Brug et GRC-setup, der gør vurdering og efterprøvning gentagelig - med fokus på tjenesterelevans og evidens:


  1. Opret hændelsen
    Tid, ejer, berørte tjenestekomponenter/kunder, kort beskrivelse. Klassificér i hvilket omfang hændelsen er væsentlig.

  2. Anvend jeres tærskler
    Omfang, varighed, kritikalitet, datatyper, kædeeffekt, genopretning. Gem datapunkter (målinger, loguddrag).

  3. Beslutning & eskalering
    Hvem besluttede hvad hvornår (navn/rolle/tid). Rapportér efter dansk vejledning (early warning ~24t., notifikation ~72 t., endelig rapport ~1 måned - jf. national praksis).

  4. Handlinger & opgaver
    Inddæmning, fix, gendannelse, kommunikation; tildel ansvar og deadlines; vedhæft evidens.

  5. RCA & forbedringer
    Root cause, læringspunkter, opdaterede kontroller/risici; lukning med ledelsesgodkendelse og kort konklusion. (ENISA anbefaler konsistent RCA og endelig hændelsesrapport).


Hvordan dette styres i Complychain:

I Complychain kan hændelsen knyttes til kunder, leverandører og underdatabehandlere, relevante kontroller på tværs af NIS2/ISO 27001/ISAE 3000 (mm.), og hele beslutnings- og evidenssporet kan genbruges i rapportering.



Quick checklist: 5 spørgsmål du bør kunne svare på


  1. Påvirker hændelsen levering af vores tjeneste (direkte eller via leverandører/underdatabehandlere)?

  2. Hvad var omfang og varighed, og ramte det kerneprocesser/SLA?

  3. Hvilke datatyper/systemer for tjenesten var berørt - og er der tegn på misbrug?

  4. Var der kædeeffekt i tjenestekæden (upsteam/downstream), og hvordan håndterede vi den? (NIS2 styrker fokus på forsyningskæden).

  5. Hvad gjorde vi hvornår (inddæmning, kommunikation, gendannelse), og hvilke forbedringer er besluttet (RCA, opdaterede kontroller/risici)?



Sådan hjælper Complychain med NIS2 - i praksis


  • Tjenestescope på plads: Kortlæg systemer, dataflows og leverandører, der understøtter jeres tjeneste. Det gør det tydeligt, hvilke hændelser der er NIS2-relevante – og hvilke der ikke er.

  • Implementering og vedligehold: Få adgang til +144 prædefinerede kontroller, der hjælper med implementering, opdatering og vedligehold af samtlige krav under NIS2.

  • Hændelsesstyring, trin for trin: Standardiser triage med egne tærskler (omfang, varighed, SLA mv.), klassificér, tildel opgaver og gem hele tidslinjen.

  • Kædeoverblik: Knyt hændelsen til kunder, leverandører og underdatabehandlere. Se kædeeffekter hurtigt og dokumentér, hvordan de blev håndteret.

  • Kontrolmapning på tværs: Forbind hændelsen til relevante NIS2-kontroller – og genbrug arbejdet i ISO 27001 og ISAE 3000 for at undgå dobbeltarbejde.

  • Evidens der holder: Saml logs, beslutninger, kommunikation og RCA ét sted, så audit-sporet er komplet og efterprøvbart.

  • Risikoforankring: Løft læring fra hændelser ind i risikoregistret og opdater tilknyttede kontroller, så forbedringer rent faktisk bliver implementeret.


Vil du se det i praksis?


Book en 20-minutters demo og se, hvordan Complychain gør NIS2-indsatsen konsekvent, dokumenteret og skalerbar - fra hændelse til forbedring.