NIS2 tjekliste for SMV: kom i gang uden kaos (praktisk guide)

Michael Lund
for 6 dage siden
4 min læsning

Hvis NIS2 føles som endnu et krav, der lander midt i en travl hverdag, er du ikke alene. For mange SMV’er handler det ikke om at blive “perfekte” på cybersikkerhed, men om at få styr på det vigtigste, og kunne vise det, når nogen spørger.

Denne guide giver dig en praktisk NIS2 tjekliste du kan kopiere direkte, plus små skabeloner og eksempler på “minimum viable compliance”. Tænk på det som en brandslukker og en brandøvelse, ikke en 200-siders håndbog.

Hvad betyder NIS2 for en SMV i januar 2026?

NIS2 er EU’s krav til cybersikkerhed for udvalgte sektorer og leverandørkæder. I Danmark er reglerne implementeret, og kravene har været gældende siden 1. juli 2025. Der var også en frist for selvregistrering (1. oktober 2025), og tilsyn og indledende kontroller er i gang her i starten af 2026.

Det vigtige for en SMV er typisk tre ting:

Du skal kunne
(ikke bare købe værktøjer).
Du skal kunne
og rapportere inden for frister (ofte 24 timer, 72 timer, 30 dage).
Du skal have styr på
, fordi et angreb ofte kommer via en tredjepart.

Til hurtig afklaring og inspiration kan du bruge oversigten med værktøjer og vejledninger hos IT-Branchens NIS2-ressourcer.

Illustration af en rolig SMV-hverdag, hvor tjekliste og sikkerhed bliver løst i fællesskab, skabt med AI.

Før du løber: afgræns om I er omfattet, og udpeg én ansvarlig

Kaos starter ofte her: ingen ved, om man er omfattet, og alle tror, “IT” ejer det hele.

Gør det i denne rækkefølge:

1) Afklar om I er omfattet Start med sektor og størrelse (medarbejdere, omsætning), og om I leverer kritiske ydelser til nogen, der er omfattet.

2) Udpeg en NIS2-ansvarlig Det behøver ikke være en sikkerhedschef. Det kan være en driftsansvarlig eller COO, som kan samle tråde og få beslutninger.

3) Definér “kritiske tjenester” Skriv 5-10 linjer om, hvad der absolut skal virke for at I kan drive forretning (mail, ERP, webshop, produktion, supporttelefon, fjernadgang).

Hvis du vil have en hurtig, praktisk selvtest, kan NIS2Verify’s gratis compliance-checkliste give et groft overblik over typiske krav og emner (brug den som startpunkt, ikke som facit).

Overblik og ansvar

Vi har afklaret om vi er omfattet (sektor, størrelse, leverandørrolle)
NIS2-ansvarlig er udpeget, med mandat til at få ting gjort
Kritiske tjenester og systemer er kortlagt (max 1 side)
Vi har en simpel risikovurdering (top 10 risici, sandsynlighed, konsekvens)
Vi ved hvilke data der er “mest følsomme” og hvor de ligger

Grundkontroller (det der stopper de fleste angreb)

MFA er slået til for mail, fjernadgang, admin-konti og økonomisystem
Adgange følger “mindst mulig adgang”, og admin-konti bruges kun til admin
Patch-plan findes (hvem, hvornår, hvad er “kritisk”)
Endpoint-beskyttelse er aktiv på alle enheder, inkl. servere
Backup kører efter 3-2-1-princippet, og restore-test er planlagt
Kritiske systemer har en ejer (forretning) og en teknisk ansvarlig (IT)

Drift, logning og rapportering

Vi har en incident-proces (hvem gør hvad de første 60 minutter)
Kontaktliste er opdateret (intern, IT-partner, kritiske leverandører)
Vi kan dokumentere logning på de vigtigste systemer (minimum)
Leverandører er vurderet (kritiske leverandører først)
Vi har træning/awareness minimum 2 gange årligt
Vi har øvet en hændelse mindst én gang (tabletop er fint)

30 dage, 90 dage, 180 dage: sådan kommer du i mål uden panik

Du får mest ro ved at arbejde i bølger.

0-30 dage (basis) Få MFA på plads, få backup og restore-test i kalenderen, og skriv en 1-sides incident-proces. Det giver effekt med det samme.

31-90 dage (bevis og rutiner) Gør patching til en rytme, få styr på admin-adgange, og lav leverandørkrav til de 5 vigtigste leverandører. Saml dokumentation ét sted.

91-180 dage (moden drift) Træn medarbejdere, kør en øvelse, og få bedre logning på de systemer, der betyder mest. Her flytter I jer fra “vi håber” til “vi ved”.

Tip: Hvis I kører Microsoft 365, så tænk backup og gendannelse som en fast del af compliance. Se en praktisk vinkel i NIS2-krav og backup for SMV’er i Microsoft 365.

“Minimum viable compliance”: konkrete eksempler der tæller

Det her er ikke fancy, men det virker, og det er ofte nok til at bestå de første spørgsmål.

Eksempel 1: MFA og admin-kontrol Minimum: MFA på alt vigtigt, separate admin-konti, og kvartalsvis gennemgang af rettigheder. Dokumentation: et skærmbillede af MFA-politik og en simpel adgangslog (dato, hvem, ændring).

Eksempel 2: Backup der kan gendannes Minimum: Daglig backup, offline eller immutabel kopi, og en restore-test hver kvartal. Dokumentation: backup-rapport, plus “restore-test udført” med dato og resultat.

Eksempel 3: Incident-proces som folk kan følge Minimum: én side med roller og første handlinger. Dokumentation: version, dato, og hvem der godkendte den.

For en kort forklaring af NIS2-rammen og typiske krav kan du også læse overblikket over NIS 2-direktivet.

Skabelon-uddrag (kort og brugbart)

Brug dem som start, og tilpas til jeres virksomhed.

Incident-rapport (uddrag)

Dato og tidspunkt: __________ Opdaget af: __________ Hvad skete der (kort): __________ Berørte systemer/tjenester: __________ Berørte data (ja/nej og type): __________ Første handlinger (0-60 min): __________ Midlertidig løsning: __________ Vurdering af påvirkning (drift/økonomi): __________ Skal der rapporteres (ja/nej): __________ Næste opdatering senest: __________ Ansvarlig for opfølgning: __________

Backup-politik (uddrag)

Omfang: Kritiske systemer og Microsoft 365-data Frekvens: Daglig backup, minimum 30 dages retention Beskyttelse: En kopi offline eller immutabel Restore-test: Hver 3. måned, dokumenteres med resultat RPO/RTO (mål): RPO ___ timer, RTO ___ timer Ejer: __________, Godkendt af: __________ (dato: ___)

Leverandørkrav (uddrag)

Krav om MFA for administrative adgange (ja/nej) Patch-tider for kritiske sårbarheder: ___ dage Hændelsesvarsling til os: senest ___ timer efter opdagelse Logning: adgangslogs gemmes minimum ___ dage Underleverandører: skal oplyses og godkendes ved kritiske ændringer Backup/beredskab: leverandøren kan dokumentere restore-test