Incident response-plan: gratis skabelon til NIS2 og GDPR

En incident response-plan beskriver, hvem der gør hvad, når virksomheden bliver ramt af en IT-sikkerhedshændelse som ransomware eller et databrud: hvem der leder, hvem der anmelder til myndighederne, og hvordan systemerne kommer op igen. NIS-2 kræver procedurer for hændelseshåndtering og anmeldelse inden for 24 og 72 timer, og GDPR kræver anmeldelse af persondatabrud inden for 72 timer. Nedenfor finder I en skabelon, I kan kopiere og tilpasse.

Hvorfor skal planen ligge klar før hændelsen?#

Fordi fristerne begynder at løbe, i det øjeblik I opdager hændelsen. Det er tirsdag kl. 06.42. Serveren svarer ikke. Filerne har fået nye endelser. Der ligger en note på skrivebordet med en Bitcoin-adresse. Klokken tikker: Er I omfattet af NIS-2, har I 24 timer til at sende en tidlig varsling, og GDPR giver jer 72 timer til at anmelde til Datatilsynet, hvis der er personoplysninger involveret. Ledelsen ringer. Kunder ringer. Pressen ringer måske også.

Det er ikke tidspunktet at finde ud af, hvem der skriver til myndighederne, hvem der taler med pressen, eller hvor backup ligger. Det skal være afklaret på forhånd.

Skabelonen i denne artikel kan tages i brug samme uge. Den er skrevet med NIS-2 artikel 21, stk. 2, litra b, og artikel 23 samt GDPR artikel 33 for øje. Foretrækker I at udfylde en plan direkte i browseren, har vi også en gratis beredskabsplan-skabelon.

Hvilke lovkrav gælder for hændelseshåndtering under NIS2 og GDPR?#

NIS-2 kræver, at omfattede virksomheder har procedurer for hændelseshåndtering og anmelder væsentlige hændelser inden for faste frister. GDPR kræver, at alle virksomheder anmelder persondatabrud til Datatilsynet inden for 72 timer. GDPR stiller ikke krav om en egentlig plan, men uden en plan er fristen svær at overholde.

NIS-2 artikel 21, stk. 2, litra b, kræver, at omfattede virksomheder har procedurer for hændelseshåndtering. Litra c kræver desuden driftskontinuitet og krisestyring, og litra f kræver, at I vurderer, om jeres foranstaltninger virker. I praksis betyder det en dokumenteret plan, der bliver testet.

NIS-2 artikel 23 sætter frister for anmeldelse af væsentlige hændelser:

• ✓24 timer: tidlig varsling (early warning)
• ✓72 timer: hændelsesunderretning med en første vurdering
• ✓1 måned efter hændelsesunderretningen: endelig rapport med rodårsag og afhjælpning

GDPR artikel 33 kræver, at persondatabrud anmeldes til Datatilsynet inden for 72 timer, efter I er blevet bekendt med dem, medmindre det er usandsynligt, at bruddet indebærer en risiko for de registrerede. Læs mere i guiden til 72-timers-fristen.

Bemærk overlappet: et ransomware-angreb kan udløse begge regelsæt samtidigt. NIS-2 gælder for sikkerhedshændelser bredt, mens GDPR gælder, når personoplysninger er kompromitteret. Jeres plan skal håndtere begge parallelt.

Hvad skal en incident response-plan indeholde?#

En incident response-plan skal indeholde syv dele: kritiske systemer, roller, kommunikation, tekniske procedurer, genopretningsmål, test og dokumentation. Den behøver ikke at være et tykt dokument, men den skal være så præcis, at jeres vagthavende IT-medarbejder kl. 03 kan følge den uden at ringe til nogen først.

1. Kritiske systemer og data

Uden en oversigt over, hvad der er kritisk, ved I ikke, hvornår en hændelse er "væsentlig". Listen skal indeholde:

• ✓Systemer, der understøtter kritisk forretningsdrift (ERP, økonomi, produktion, kundeportal)
• ✓Systemer, der indeholder personoplysninger (CRM, HR, sundhedsdata, kundedatabase)
• ✓Systemer, der har afhængigheder til andre kritiske systemer
• ✓Ejer af hvert system (teknisk og forretningsmæssig)
• ✓RTO (Recovery Time Objective) og RPO (Recovery Point Objective) pr. system

2. Roller og ansvarsfordeling

En hændelse løses ikke af "IT". Den løses af et team med klart definerede roller:

• ✓Incident Commander: den, der træffer beslutninger og har mandat
• ✓Teknisk leder: koordinerer tekniske undersøgelser og genopretning
• ✓Kommunikationsansvarlig: myndigheder, kunder, presse, medarbejdere
• ✓Juridisk / DPO: vurderer anmeldelsespligt og juridiske konsekvenser
• ✓Ledelsesrepræsentant: beslutninger med økonomisk eller strategisk konsekvens
• ✓Logbogsfører: dokumenterer alt, der sker (nødvendigt for senere rapportering)

Alle roller skal have en stedfortræder. En plan, der falder, hvis Incident Commander er på ferie, er ikke en plan.

3. Kommunikationsplan

Kommunikationsplanen fastlægger, hvem der informerer hvem, hvornår og hvordan:

• ✓Interne kanaler (ikke via det mailsystem, der muligvis er kompromitteret; brug telefon eller en ekstern kanal som Signal)
• ✓Kunder og partnere (skabeloner klar til udfyldning)
• ✓Myndigheder (anmeldelse via virk.dk til sektormyndighed og CSIRT, Datatilsynet, politiet)
• ✓Presse (én talsperson; de andre henviser til vedkommende)
• ✓Medarbejdere (så de ikke hører det først på LinkedIn)

4. Tekniske procedurer

De konkrete tekniske skridt, opdelt efter hændelsestype:

• ✓Ransomware: isolér, bevar beviser, anmeld til politiet og myndighederne, før en løsesum overhovedet overvejes
• ✓Databrud: identificér omfang, log hvad der blev tilgået, isolér adgang
• ✓DDoS: aktivér DDoS-beskyttelse, kontakt internetudbyderen, omdiriger trafik
• ✓Kompromitteret konto: nulstil adgangskoder og sessioner, gennemgå aktivitetslog, tjek om angriberen har bevæget sig videre i netværket
• ✓Phishing / BEC: identificér modtagere, stop transaktioner, informér banken

5. RTO, RPO og genopretning

Dokumentér for hvert kritisk system, hvornår det skal være oppe igen, og hvor meget data I kan tåle at miste:

• ✓RTO: hvor længe kan systemet være nede (fx 4 timer for CRM, 1 time for økonomi)
• ✓RPO: hvor gammel må den seneste brugbare backup være (fx maks. 1 time for økonomi)
• ✓Backup-strategi: 3-2-1 (tre kopier, to forskellige medier, én uden for huset), gerne med en kopi, der ikke kan ændres (immutable)
• ✓Gendannelsesprocedure: testet inden for de sidste seks måneder

6. Test og øvelser

En plan, der aldrig er testet, holder sjældent i praksis. Vi anbefaler som minimum:

• ✓Table-top-øvelse hvert halve år (to timer, hvor et scenarie gennemgås mundtligt)
• ✓Teknisk gendannelsestest hvert halve år (faktisk gendannelse fra backup)
• ✓Fuld beredskabsøvelse én gang om året (gerne med ekstern facilitator)
• ✓Dokumentér hver test: dato, scenarie, deltagere, læringspunkter, opfølgning

7. Dokumentation og læring

Under hændelsen: logbog med tidsstempler, beslutninger og handlinger. Efter hændelsen: post-mortem uden skyld, hvor I identificerer rodårsag, hvad der virkede, hvad der ikke virkede, og konkrete forbedringer med ejer og deadline.

Incident response-skabelon: kopiér og tilpas#

Herunder er selve incident response-planen. Ret firmanavn, kontaktinformationer og systemer til jeres virkelighed, og få den godkendt af ledelsen.

INCIDENT RESPONSE-PLAN: [FIRMANAVN]

Version: 1.0

Ikrafttræden: [DATO]

Ejer: [IT-CHEF / CISO / CTO]

Godkendt af: [DIREKTION / BESTYRELSE]

Næste revision: [DATO: maks. 12 måneder]

1. Formål

Denne plan sikrer, at [FIRMANAVN] kan reagere hurtigt, koordineret og lovmedholdeligt på IT-sikkerhedshændelser. Planen dækker krav i NIS-2 Art. 21(2)(b) og Art. 23 samt GDPR Art. 33.

2. Definitioner

Hændelse: enhver begivenhed, der påvirker fortrolighed, integritet eller tilgængelighed af [FIRMANAVN]s data eller systemer.

Væsentlig hændelse (NIS-2): en hændelse, der forårsager eller kan forårsage alvorlig driftsforstyrrelse eller økonomisk tab, eller berører andre fysiske eller juridiske personer med betydelig materiel eller immateriel skade.

Persondatabrud (GDPR): brud på sikkerheden, der fører til hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger.

3. Kritiske systemer

4. Incident response-team

Teamet mødes fysisk eller via [BACKUP-KANAL: fx Signal-gruppe], når en hændelse aktiveres.

5. Klassificering

• ✓P1. Kritisk: kritiske systemer nede, persondata kompromitteret, aktivt ransomware, eller væsentlig hændelse efter NIS-2. Aktivér fuldt team øjeblikkeligt.
• ✓P2. Høj: ét kritisk system påvirket eller mistanke om persondatabrud. Aktivér Incident Commander, teknisk leder, juridisk.
• ✓P3. Middel: ikke-kritiske systemer påvirket, ingen kendt datapåvirkning. Håndteres af IT under normal drift.
• ✓P4. Lav: enkeltbruger-hændelser, ingen systemisk risiko.

Ved tvivl klassificeres opad.

6. Response-faser

Fase 1. Identifikation (0-1 t)

• ✓Bekræft hændelsen (ikke en fejlalarm)
• ✓Klassificér P1-P4
• ✓Aktivér relevant team
• ✓Start logbog med tidsstempler

Fase 2. Inddæmning (1-4 t)

• ✓Isolér berørte systemer (net-segmentering, deaktiverede konti)
• ✓Bevar beviser (memory dumps, logs, disk images før restore)
• ✓Undgå at slette noget der kan være bevis
• ✓Ved ransomware: anmeld til politiet og kontakt jeres rådgivere, før der træffes beslutning om løsesum

Fase 3. Udbedring (4-72 t)

• ✓Fjern truslen (opdateringer, nulstilling af adgangskoder, isolering)
• ✓Verificér, at systemet er rent, før gendannelse
• ✓Gendan fra en backup, I ved er ren
• ✓Overvåg for genkomst

Fase 4. Rapportering (24-72 t / 1 md.)

• ✓NIS-2 tidlig varsling: 24 t via virk.dk (skabelon 8A)
• ✓NIS-2 hændelsesunderretning: 72 t (skabelon 8B)
• ✓GDPR-anmeldelse: 72 t til Datatilsynet hvis persondata (skabelon 8C)
• ✓NIS-2 endelig rapport: 1 måned efter hændelsesunderretningen
• ✓Berørte kunder og registrerede informeres, når reglerne kræver det (GDPR artikel 34, NIS-2 artikel 23, stk. 1)

Fase 5. Læring (2-4 uger efter)

• ✓Post-mortem uden skyld
• ✓Rodårsag identificeret og dokumenteret
• ✓Konkrete forbedringer med ejer og deadline
• ✓Planen opdateres om nødvendigt

7. Kommunikation: eksterne kontakter

8. Rapporterings-skabeloner

8A. NIS-2 tidlig varsling (24 timer) via virk.dk

• ✓Firmanavn og CVR: [X]
• ✓Sektor og NIS-2-kategori (væsentlig/vigtig enhed): [X]
• ✓Kontaktperson og tlf.: [X]
• ✓Tidspunkt for opdagelse (dato + tid, DK-tid): [X]
• ✓Kort beskrivelse af hændelsen (2-3 sætninger): [X]
• ✓Foreløbig vurdering: mistanke om ulovlig eller ondsindet handling? (ja/nej/ukendt): [X]
• ✓Foreløbig vurdering: potentiel grænseoverskridende påvirkning? (ja/nej): [X]
• ✓Iværksatte foranstaltninger: [X]
• ✓Næste opdatering forventes: [X]

8B. NIS-2 hændelsesunderretning (72 timer) via virk.dk

Ovenstående plus:

• ✓Bekræftet omfang og alvor
• ✓Berørte systemer og tjenester
• ✓Antal berørte brugere/kunder (estimeret)
• ✓Rodårsag hvis kendt (ellers status på undersøgelse)
• ✓Kompromitteringsindikatorer (IoCs) hvis relevant
• ✓Igangværende og planlagte foranstaltninger
• ✓Behov for assistance fra den nationale CSIRT

8C. GDPR Art. 33-anmeldelse (72 timer) til Datatilsynet via virk.dk

• ✓Dataansvarlig: navn, CVR, adresse
• ✓DPO / kontaktperson: navn, tlf., mail
• ✓Tidspunkt for bruddet (fra/til, hvis kendt) og tidspunkt for kendskab
• ✓Beskrivelse af bruddets karakter: hvilke oplysninger, hvordan skete det
• ✓Kategorier af registrerede: [medarbejdere / kunder / patienter / børn / ...]
• ✓Cirka antal registrerede berørt: [X]
• ✓Cirka antal registreringer berørt: [X]
• ✓Sandsynlige konsekvenser af bruddet
• ✓Trufne og foreslåede foranstaltninger (herunder afhjælpning af skadevirkning)
• ✓Er de registrerede underrettet? Hvis nej, hvornår og hvordan?

De faktiske felter i anmeldelserne står i formularerne på virk.dk. Listerne her er til at samle oplysningerne på forhånd.

9. Test og øvelser

• ✓Table-top øvelse hver 6. måned
• ✓Restore-test fra backup hver 6. måned
• ✓Fuld beredskabsøvelse årligt
• ✓Alle test dokumenteres i [BILAG A: testlog]

10. Vedligeholdelse

Planen revideres:

• ✓Årligt som minimum
• ✓Efter enhver P1- eller P2-hændelse
• ✓Ved væsentlige ændringer i systemer, roller eller lovgivning

Ejer af planen: [NAVN, ROLLE]. Godkendelse: [DIREKTION/BESTYRELSE].

Sådan tester I jeres incident response-plan#

I tester planen med tre øvelser af stigende omfang: en table-top-øvelse, en gendannelsestest og en fuld beredskabsøvelse.

Table-top-øvelse (to timer, hvert halve år)

Saml teamet omkring et bord. En facilitator (ekstern eller en fra teamet, der ikke selv deltager i håndteringen) læser et scenarie op: "Kl. 07.15 opdager driftschefen, at ERP-systemet ikke svarer. En Bitcoin-note ligger på skrivebordet." Teamet gennemgår mundtligt, hvad de gør: hvem ringer til hvem, hvordan hændelsen klassificeres, og hvornår den tidlige varsling sendes. Facilitatoren kaster komplikationer ind undervejs: "Økonomidirektøren er på ferie i Thailand. Hvordan får I ledelsesbeslutninger?"

Udbytte: I finder huller i planen på to timer, uden at driften afbrydes.

Gendannelsestest (en halv dag, hvert halve år)

Vælg ét kritisk system. Gendan det fra jeres seneste backup i et testmiljø (ikke i produktionen). Kontrollér, at data er intakte, og mål, hvor lang tid det tog. Sammenlign med RTO/RPO i planen.

Udbytte: I opdager, hvis backuppen ikke virker, før I får brug for den. Her fejler mange planer.

Fuld beredskabsøvelse (én dag, årligt)

Kombiner de to. Kør et realistisk scenarie, hvor teamet både skal træffe beslutninger og gennemføre tekniske handlinger. Involvér ledelsen, test kommunikationskanalerne, og skriv anmeldelserne til myndighederne, som om det var virkeligt (uden at sende dem).

Udbytte: I ser, hvad der sker under pres, og ender med en bedre plan og et team, der ved, hvad det skal.

Dokumentér alle tests. En NIS-2-tilsynsmyndighed kan spørge, hvornår I testede planen, hvad scenariet var, og hvad I rettede bagefter. Uden en testlog er det svært at vise, at planen virker.

ShieldUps NIS-2-spor med otte moduler er i beta og dækker blandt andet hændelseshåndtering og ledelsens ansvar. Denne skabelon plus en table-top-øvelse er et godt sted at starte.

Ofte stillede spørgsmål om incident response#

Hvornår er en hændelse "væsentlig" under NIS2?

Ifølge NIS-2 artikel 23, stk. 3, er en hændelse væsentlig, hvis den forårsager eller kan forårsage alvorlig driftsforstyrrelse eller økonomisk tab for jer, eller påvirker andre fysiske eller juridiske personer ved at forårsage betydelig materiel eller immateriel skade. Styrelsen for Samfundssikkerhed har en vejledning om hændelsesunderretning med nærmere kriterier. Er I i tvivl, er det som regel bedre at sende en tidlig varsling, der viser sig at være mindre alvorlig, end at undlade at varsle.

Skal vi anmelde en hændelse under både NIS2 og GDPR?

Ofte ja. En væsentlig NIS-2-hændelse, der også rammer persondata, udløser begge anmeldelsespligter. NIS-2-anmeldelsen (artikel 23) går til jeres kompetente myndighed og CSIRT, og GDPR-anmeldelsen (artikel 33) går til Datatilsynet. De er selvstændige anmeldelser med hver sine felter og frister. Skabelon 8A-8C i planen dækker begge.

Må vi betale løsesum ved ransomware?

Der er ingen generel dansk lov, der forbyder det, men myndighederne fraråder det. Betaling finansierer kriminalitet, giver ingen garanti for, at dekrypteringen virker, og kan gøre jer til mål for nye angreb. Anmeld til politiet, og tal med jeres rådgivere og forsikringsselskab, før I træffer en beslutning. Den bedste forsikring mod dilemmaet er en backup, der ikke kan ændres. På vores ransomware-tracker kan I se, hvor ofte danske virksomheder bliver ramt.

Hvor længe skal vi opbevare logs efter en hændelse?

Der er ingen fast frist i NIS-2 eller GDPR. En udbredt anbefaling er mindst 12 måneder for sikkerhedslogs. Efter en konkret hændelse bør I gemme relevante logs, diskbilleder og dokumentation, indtil sagen er endeligt afsluttet, og eventuelle rets- eller tilsynssager er ovre. Slet ikke noget under en igangværende myndigheds- eller politisag, og husk, at logs med personoplysninger også er omfattet af GDPR.

Hvor anmelder man en NIS2-hændelse i Danmark?

Siden 1. juli 2025 anmeldes væsentlige hændelser via virk.dk. Anmeldelsen går til jeres kompetente sektormyndighed og til den nationale CSIRT, som varetages af Forsvarets Efterretningstjeneste. Styrelsen for Samfundssikkerhed har en vejledning om hændelsesunderretning på samsik.dk. Læg det konkrete link ind i planen, så det ikke skal googles kl. 03 om natten.

Se også: NIS-2-selvtjek · GDPR-guide og 72-timers-beregner · Forskningen bag ShieldUp

Kilder#

Regulatoriske primærkilder og officielle vejledninger.

NIS-2: regulatorisk primærkilde

• ✓Europa-Parlamentet og Rådet (2022). Direktiv (EU) 2022/2555 (NIS-2). Art. 21 (risikohåndteringsforanstaltninger, herunder hændelseshåndtering), Art. 23 (rapporteringsforpligtelser: tidlig varsling inden for 24 timer, hændelsesunderretning inden for 72 timer, endelig rapport inden for 1 måned). Link

GDPR: regulatorisk primærkilde

• ✓Europa-Parlamentet og Rådet (2016). Forordning (EU) 2016/679 (GDPR). Art. 33 (anmeldelse af brud på persondatasikkerheden til tilsynsmyndigheden), Art. 34 (underretning af den registrerede). Link

Danske myndigheder

• ✓Styrelsen for Samfundssikkerhed. NIS 2-vejledninger, herunder vejledning om hændelsesunderretning (2025). Link
• ✓Styrelsen for Samfundssikkerhed (2025). Vejledning til NIS 2-loven: hændelsesunderretning. Link
• ✓Datatilsynet (2025). Håndtering af brud på persondatasikkerheden, vejledning. Link

Standarder for hændelseshåndtering

• ✓NIST SP 800-61 Rev. 3 (2025). Incident Response Recommendations and Considerations for Cybersecurity Risk Management. Erstatter Rev. 2. Link
• ✓ENISA (2010). Good Practice Guide for Incident Management. Link

Tjek det på 30 sekunder med vores interaktive selvtjek.