En sikkerhedsaudit af virksomheden ser på, hvordan organisationen beskytter sine egne systemer og data. En gennemgang af et softwareprodukt ser på, om det produkt, I sælger til andre, er udviklet og vedligeholdt sikkert. Den virksomhed, der både driver IT og udvikler software, kan blive mødt af to forskellige regelsæt med hver sin genstand.
Forvirringen er forståelig. Begge handler om cybersikkerhed, begge kommer fra EU, og de samme udviklere og driftsfolk indgår i begge. Men spørgsmålene, der stilles, er forskellige, og et godt svar på det ene dækker ikke det andet.
Regelsættet for virksomheden
NIS 2-loven, lov nr. 434 af 6. maj 2025, trådte i kraft 1. juli 2025 og gennemfører EU’s NIS 2-direktiv. Den rammer offentlige og private organisationer inden for sektorerne i bilag 1 og 2, når de har en vis størrelse.
Kravene retter sig mod enheden, altså organisationen. Paragraf 6 handler om de foranstaltninger, der styrer risikoen for organisationens egne systemer, og § 7 lægger godkendelsen af dem og tilsynet med dem hos ledelsesorganet. Det er virksomhedens egen drift, der er i centrum. En audit efter loven er beskrevet i hvad er en NIS2-audit.
Regelsættet for produktet
Forordning (EU) 2024/2847 af 23. oktober 2024, forordningen om cyberrobusthed, kendt som Cyber Resilience Act eller CRA, handler om produkter. Den gælder efter artikel 2, stk. 1, for produkter med digitale elementer, som gøres tilgængelige på EU-markedet, og hvis formål eller forudsigelige brug omfatter en direkte eller indirekte dataforbindelse til andet udstyr eller til et net. Et produkt med digitale elementer er efter artikel 3, nr. 1, et software- eller hardwareprodukt og de løsninger til fjerndatabehandling, der hører til det.
Forordningen gælder ikke på én gang. Efter artikel 71, stk. 2, gælder den fra 11. december 2027. Reglerne i artikel 14 om fabrikantens pligt til at rapportere aktivt udnyttede sårbarheder og alvorlige hændelser gælder dog fra 11. september 2026, og kapitel IV, artikel 35 til 51, fra 11. juni 2026. Pr. november 2026 gælder artikel 14 og kapitel IV altså allerede, mens resten af forordningen endnu ikke gælder. Datoerne er tjekket mod den konsoliderede tekst på skrivedagen.
Denne artikel handler om software. Producenter af fysiske produkter har deres egne spørgsmål, som ikke er emnet her.
To forskellige genstande
Det er vores tolkning, at de to regelsæt har forskellig genstand. NIS 2-loven spørger, om virksomheden har styr på sin egen sikkerhed. CRA spørger, om produktet, der sendes ud til kunderne, lever op til forordningens krav, og om fabrikanten håndterer sårbarheder i det.
Et tænkt eksempel gør det tydeligt. En softwarevirksomhed har stram adgangsstyring, testet backup og en godkendt sikkerhedspolitik. En NIS2-audit af virksomheden ville måske finde få huller. Men hvis produktet sendes ud med et standardpassword, og der ikke er en proces for at modtage og rette indmeldte sårbarheder, er det et problem for produktet, som virksomhedsauditten ikke er bygget til at finde.
Omvendt kan et velbygget produkt komme fra en virksomhed, hvis egne systemer står åbne.
Hvor de mødes
Der er områder, hvor de to overlapper. Udviklingsmiljøet, kildekoden og byggesystemet er virksomhedens egne systemer og indgår i en audit af virksomheden. De er samtidig der, hvor produktets sikkerhed bliver skabt. Håndtering af sårbarheder optræder også begge steder: i virksomhedens egne systemer og i produktet.
En almindelig måde at planlægge på er at lade virksomhedsauditten dække udviklingsmiljøet som en del af driften, og lade gennemgangen af produktet dække udviklingsprocessen, sårbarhedshåndteringen og det, der sendes ud. Så bruges beviset ét sted og læses med to spørgsmål.
Hvem gør hvad
Gennemgangen af softwareprodukter og udviklingsprocesser efter CRA er emnet for Cyber Resilience Act for softwareproducenter. Her på sitet handler det om virksomhedens sikkerhed. Den virksomhed, der også er omfattet af NIS 2-loven og producerer, kan læse NIS 2 og CRA i fremstillingsvirksomheden.
Ved bestillingen er det vigtigt, at opdraget siger, hvilken genstand auditten har. Står der blot “sikkerhedsaudit”, vil de fleste forstå det som virksomheden. Se opdraget på én side.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at I gør op, om I er omfattet af NIS 2-loven, om I gør produkter med digitale elementer tilgængelige på markedet, eller begge dele. Derefter bør hver have sin ejer, typisk IT-chefen eller den sikkerhedsansvarlige for virksomheden og en udviklings- eller produktansvarlig for produktet.
Blandes de to sammen, risikerer I at få en audit, der ser grundig ud, men som har gennemgået det forkerte. Produktets sårbarhedshåndtering kan stå ubehandlet, fordi alle tror, den var med i virksomhedsauditten.
Det skal I lade være med
- At lade en virksomhedsaudit stå som svar på produktkrav · den har en anden genstand.
- At skrive fremtidige frister som gældende · det meste af CRA gælder først fra december 2027.
- At glemme udviklingsmiljøet · det hører til både virksomheden og produktet.
Det skal auditten kunne vise
- ☐ Hvilken genstand auditten har: virksomheden, produktet eller begge.
- ☐ Om udviklingsmiljø og byggesystem er med i virksomhedens omfang.
- ☐ Hvem der ejer virksomhedens sikkerhed, og hvem der ejer produktets.
- ☐ Hvilke af reglerne, der gælder på auditdagen, og hvilke der først gælder senere.
Kilder
- Retsinformation, Lov nr. 434 af 6. maj 2025 (NIS 2-loven), §§ 1, 6 og 7, https://www.retsinformation.dk/eli/lta/2025/434, læst 12. november 2026.
- Europa-Parlamentets og Rådets forordning (EU) 2024/2847 af 23. oktober 2024 (forordningen om cyberrobusthed), artikel 2, 3, 14 og 71, https://publications.europa.eu/resource/celex/32024R2847, læst 12. november 2026. Konsolideret udgave og ændringsoplysninger tjekket samme dag.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Hvad er en sikkerhedsaudit · Auditkriterier
→ Kontakt · Tlf. 70 13 63 23 · Cybersikkerhedsaudit hos Nielco IT
