NIS2 gør noget meget klassisk for regulering: den siger ikke “køb produkt X og sov roligt”. Den siger: “I skal kunne håndtere hændelser. I skal kunne dokumentere det. Og I skal kunne gøre det hurtigt.”
Det betyder, at incident response (IR) ikke længere er noget, der kun ligger i sikkerhedsafdelingen eller hos en ekstern leverandør. Det er et ledelses- og driftskrav: jeres organisation skal have et beredskab, der faktisk virker i virkeligheden, når det brænder på.
I denne artikel får du en praktisk og brugbar gennemgang af, hvad et NIS2-kompatibelt incident response-beredskab typisk skal kunne. Fokus er ikke på “flotte planer”, men på capability: roller, processer, værktøjer og øvelser, der gør jer i stand til at opdage, reagere, begrænse skade og rapportere korrekt.
Hvorfor incident response bliver centralt under NIS2
Mange virksomheder har i dag en kombination af:
- et “policy-dokument” om beredskab (som ingen læser)
- en IT-drift, der kan fikse ting, når de går ned
- en leverandør/MSSP, der måske overvåger noget
- en ledelse der først bliver involveret, når skaden er sket
NIS2 skubber jer mod noget mere konkret: et incident response-setup der kan håndtere både:
- klassiske IT-hændelser (driftsnedbrud, datatab)
- cybersikkerhedshændelser (ransomware, kompromitterede konti, datalæk)
- leverandørhændelser (SaaS/MSP-nedbrud, supply chain)
Og det er især vigtigt fordi hændelser sjældent udvikler sig “pænt”. De starter småt, bliver opdaget sent, og bliver dyrere hvert døgn.
Hvad “incident response” reelt betyder (uden compliance-sprog)
Incident response er jeres evne til at:
- Opdage at noget er galt
- Vurdere hvor alvorligt det er og hvad der er ramt
- Begrænse skaden hurtigt (containment)
- Fjerne årsagen (eradication)
- Gendanne drift sikkert (recovery)
- Kommunikere korrekt internt og eksternt
- Lære af hændelsen og forbedre (post-mortem)
Hvis jeres setup ikke kan gøre de ting hurtigt, så er det i praksis ikke et beredskab. Det er et dokument.
NIS2 i praksis: hvad forventes der af jeres beredskab?
NIS2 handler overordnet om at have passende og proportionelle sikkerhedsforanstaltninger, og at kunne dokumentere, at I arbejder med det løbende. For incident response betyder det typisk:
- I skal have klare roller og ansvar (hvem gør hvad hvornår)
- I skal have processer for håndtering af hændelser
- I skal kunne detektere og reagere i rimelig tid (ikke uger senere)
- I skal kunne eskalere til ledelse og relevante interessenter
- I skal kunne dokumentere hændelser, beslutninger og tiltag
- I skal kunne håndtere leverandører som en del af IR
- I skal kunne øve og forbedre jeres beredskab
Målet er ikke at have “alt”. Målet er at have noget, der virker og matcher jeres risikoprofil.
1) Det første jeres beredskab skal kunne: opdage hændelser tidligt
Alt bliver dyrere, hvis I opdager det sent. Derfor er det vigtigste IR-krav i praksis: detection.
Minimum I bør have styr på
- Central logning af kritiske systemer (identitet, mail, endpoints, firewall/cloud)
- Alarmer på typiske “high signal”-events:
- umulige login / login fra nye lande
- masse-downloads
- ændringer i MFA/identity settings
- nye admin-konti/rolleændringer
- OAuth consent misbrug
- EDR alerts (malware, ransomware patterns)
- Overvågning af kritiske tjenester og tilgængelighed (uptime / performance)
Praktisk mål: I skal kunne opdage de mest alvorlige hændelser inden for timer, ikke uger.
2) Triage og klassifikation: I skal hurtigt kunne afgøre “hvor slemt er det?”
Når alarmen går, er det ikke tid til at diskutere definitioner.
Hav en simpel severity-model
Fx en 1–4 eller 1–5 skala baseret på:
- påvirkning på drift (nedetid, kritiske services)
- datarisiko (læk/tab)
- udbredelse (én enhed vs. hele miljøet)
- sandsynlighed for aktivt angreb
- regulatorisk/kontraktmæssig konsekvens
Målet: 15–30 minutter efter første signal skal I kunne sige:
- Hvad tror vi, det er?
- Hvad er påvirket?
- Hvad gør vi nu?
3) Containment: stop blødningen før du laver pæne slides
Containment handler om at begrænse skaden hurtigt. Det kan være:
- isolere endpoints
- deaktivere kompromitterede brugere / sessions
- blokere IP’er eller endpoints i firewall/EDR
- slå tokens/keys fra
- lukke en integration
- begrænse adgang til kritiske systemer
Den største fejl her er at være bange for at “forstyrre driften”. Hvis du har et aktivt angreb, er driften allerede forstyrret. Du er bare ikke færdig med at opdage hvor meget.
4) Eradication og recovery: fjern årsagen og gendan sikkert
Når I har begrænset skaden, skal I:
- identificere root cause (phishing? sårbarhed? leverandør? fejlkonfiguration?)
- lukke hullet (patch, config change, credential reset)
- gendanne systemer fra kendt gode backups/immutable backups
- sikre at I ikke gendanner kompromitterede miljøer
Backup-virkeligheden (som folk hader at høre)
Backups er ikke “vi har backup”. Backups er:
- kan vi gendanne inden for acceptabel tid?
- har vi testet restore?
- er backups beskyttet mod ransomware (immutable/offline)?
Hvis I ikke kan svare ja til restore-test, er backup i praksis en følelse.
5) Kommunikation: jeres beredskab skal kunne tale med mennesker
Incident response dør ofte i kommunikationen:
- IT taler teknisk
- ledelsen vil vide impact og beslutninger
- jura vil vide risiko og dokumentation
- kunder vil vide “hvad betyder det for os?”
- medarbejdere vil vide “hvad skal jeg gøre?”
Minimum-kommunikationspakke
- en intern “status template” (kort: hvad skete, hvad gør vi, hvad er næste update)
- en ekstern statement template (hvis relevant)
- en kontaktliste (ikke en forældet pdf)
- en eskaleringsvej til ledelsen
Nøglepunkt: Kommunikation skal være regelmæssig og troværdig, også når I ikke ved alt endnu.
6) Rapportering og dokumentation: I skal kunne vise hvad I gjorde og hvorfor
NIS2 handler ikke om at skrive romaner. Det handler om sporbarhed.
Det I bør kunne dokumentere uden at drukne:
- tidslinje: hvornår opdagede I hvad?
- beslutninger: hvad gjorde I, hvorfor, hvem godkendte?
- scope: hvilke systemer/data var ramt?
- tiltag: containment, eradication, recovery
- læring: hvad ændrer I bagefter?
Det kan være i et simpelt incident ticket-system eller en IR-skabelon. Det behøver ikke være fancy. Det skal være brugbart.
7) Roller og ansvar: hvem gør hvad når det brænder?
Et IR-setup uden klare roller er som en brandøvelse uden udgange.
Minimum-roller (kan være samme person i mindre virksomheder)
- Incident Commander (styrer forløbet og beslutninger)
- Tech Lead (leder den tekniske analyse og handlinger)
- Comms/Stakeholder lead (intern/ekstern kommunikation)
- Legal/Compliance kontakt (vurdering af rapportering, kontrakter)
- Vendor liaison (kontakt til MSP/SaaS/leverandører)
- Forensics/IR partner (ekstern hjælp hvis nødvendigt)
I mindre organisationer kan 2–3 personer dække det hele. Pointen er at det er defineret.
8) Leverandører: jeres beredskab skal kunne håndtere “det er ikke os, det er dem”
NIS2 skærper fokus på supply chain og afhængigheder.
Beredskabet skal kunne:
- aktivere en leverandør hurtigt (kontaktpunkter, SLA’er)
- få status og logdata (hvis muligt)
- håndtere nedbrud i kritiske SaaS/MSP
- koordinere kommunikation til kunder/internt
Hvis I ikke har leverandørkontakter og krav på plads, står I og venter, mens forretningen brænder.
9) Øvelser: I skal kunne øve, ellers kan I ikke stole på planen
Incident response er ikke noget, du finder ud af i realtid for første gang.
Start med tabletop-øvelser (lav friktion)
Kør 60–90 minutter på scenarier som:
- ransomware på filserver/SharePoint
- kompromitteret M365 konto og masse-exfiltration
- SaaS/MSP-nedbrud på kritisk proces
- data-læk fra fejl i adgangsstyring
Formålet er at finde:
- hvem ringer til hvem?
- hvad gør vi først?
- hvad mangler vi af adgang, logs, beslutninger?
Det er bedre at finde huller i en øvelse end kl. 02:14.
En praktisk “minimum version” af et NIS2 IR-beredskab (MVP)
Hvis I vil gøre det simpelt og effektivt, så sørg for at have:
- 1 side med roller, kontaktliste og eskalering
- en severity-model (1–4) og hvornår ledelsen skal ind
- logning + alarmer på de vigtigste signaler
- EDR + mulighed for isolering af enheder
- backup/restore-test dokumenteret
- en IR-runbook for 3 scenarier: phishing/identity, ransomware, leverandørnedbrud
- en plan for intern og ekstern kommunikation
- en kvartalsvis tabletop-øvelse
Det er nok til at være langt foran “vi har et dokument et sted”.
Hvis du vil have et samlet overblik over NIS2-arbejdet og hvordan incident response passer ind i helheden, kan du starte her: NIS2 incident response
Konklusion
Under NIS2 er incident response ikke et “nice to have”. Det er en konkret capability: jeres organisation skal kunne opdage hændelser, træffe hurtige beslutninger, begrænse skade, gendanne drift og dokumentere hvad der skete.
Det kræver ikke et kæmpe bureaukrati. Det kræver klare roller, simple processer, god detektion, øvelser og en plan der kan bruges under pres.
Målet er ikke at gøre alt. Målet er at kunne gøre det rigtige først og kunne vise hvorfor. Det er kedeligt. Det virker.
Leave a Reply