Cyber Resilience Act og NIS2: Hvad betyder det for virksomheder i praksis?

EU har besluttet sig for at gøre cybersikkerhed til noget, man ikke bare “gerne vil” prioritere, men noget man faktisk skal kunne dokumentere. Og nej, det er ikke kun for banker og “store tech”. To af de største nye rammer er NIS2 (krav til organisationers cybersikkerhed) og Cyber Resilience Act (CRA) (krav til cybersikkerhed i produkter med digitale elementer).

Hvis du driver en virksomhed, arbejder med IT, sælger software/IoT, eller bare gerne vil undgå at blive den næste triste case i medierne, så er her den praktiske gennemgang. Uden panik. Med fokus på hvad du konkret skal gøre.

Hvad er NIS2 i korte træk?

NIS2 er et EU-direktiv, der skærper kravene til cybersikkerhed og ledelsesansvar for en lang række sektorer. Det handler ikke om “best practice”, men om styring, beredskab, rapportering og leverandørkæde.

Hvem bliver typisk omfattet?

NIS2 rammer især virksomheder, der:

Leverer kritiske tjenester (energi, transport, sundhed, vand, digital infrastruktur, offentlig sektor m.m.)
Er en del af den vigtige økonomiske infrastruktur (fx cloud, datacentre, managed service providers, IT-drift, visse digitale tjenester)
Er mellemstore eller store (oftest 50+ ansatte og/eller en vis omsætning), men der findes undtagelser, hvor også mindre kan blive omfattet pga. rolle/samfundskritisk betydning.

Vigtig detalje: Selv hvis du ikke er direkte omfattet, kan du blive “indirekte ramt”, fordi dine kunder kræver dokumentation fra dig som leverandør.

Hvad er Cyber Resilience Act (CRA)?

CRA fokuserer på produkter med digitale elementer: software, hardware, IoT-enheder, apps, platforme, netværksudstyr, og alt det lækre, der kan opdateres, forbindes eller hackes.

CRA’s grundidé er enkel:

Hvis du sælger digitale produkter i EU, skal de være bygget og vedligeholdt på en måde, der gør dem rimeligt sikre.

Hvem bliver typisk påvirket af CRA?

Producenter og udviklere af software/hardware/IoT
Virksomheder, der “rebrander” eller videresælger produkter under eget navn
Importører og distributører (krav til kontrol og dokumentation)
I praksis også teams, der bygger plugins, integrationer, komponenter og systemer, der indgår i større løsninger

CRA handler især om:

Sårbarhedshåndtering (vulnerability management)
Secure-by-design/secure-by-default
Dokumentation og compliance (ja, papirarbejde. Tillykke.)

NIS2 vs. CRA: Hvad er forskellen i praksis?

De bliver tit blandet sammen, så lad os skære det ud:

NIS2: Handler om organisationens sikkerhed (styring, processer, beredskab, leverandører, rapportering).
CRA: Handler om produktets sikkerhed (design, udvikling, opdateringer, sårbarheder, dokumentation).

Hvis din virksomhed både leverer kritiske tjenester og sælger digitale produkter, kan du ende med at skulle leve op til begge.

Hvad betyder det her for dig… i virkeligheden?

Der er en klassisk fejl mange laver: De tror compliance er en “IT-opgave”. NIS2 og CRA skubber ansvaret op i ledelsen og ud i hele organisationen.

Her er, hvad det typisk betyder i praksis:

1) Ledelsen får ansvar (og kan ikke gemme sig)

NIS2 lægger vægt på, at ledelsen skal godkende, forstå og følge op på sikkerhedsindsatsen. Det betyder:

Sikkerhedsmål og risikotolerance skal defineres
Der skal være governance: roller, ansvar og beslutningsveje
Der skal kunne dokumenteres, at man har taget rimelige skridt

Det her bliver ikke løst af en “vi har antivirus” PowerPoint.

2) Risikovurdering bliver en fast disciplin

Du skal kunne svare på:

Hvilke systemer er vigtigst?
Hvilke trusler er mest realistiske?
Hvad er konsekvensen, hvis X går ned eller lækkes?
Hvilke kontroller har vi, og hvor er hullerne?

En god risikovurdering er ikke 80 sider. Den er kort, opdateret og koblet til handling.

3) Incident response og rapportering skal fungere

NIS2 stiller skærpede krav til håndtering og rapportering af sikkerhedshændelser. Praktisk betyder det:

Du skal have en incident-plan, der ikke bare findes, men også virker
Du skal vide, hvem der gør hvad, hvornår
Du skal kunne logge, undersøge, begrænse og lære af hændelser

Hvis jeres “beredskab” er at skrive i Slack “er der nogen der ved hvad der sker?”, så er det nu, I skal opgradere.

4) Leverandørkæden bliver dit problem

Under NIS2 forventes det, at du styrer risiko i relation til leverandører:

Cloud-udbyder, host, MSP, betalingsløsninger, integrationspartnere, SaaS-værktøjer
Adgange, dataflow, underdatabehandlere
Krav i kontrakter, audits, minimumskontroller

Hvis jeres forretning hviler på tredjepartssystemer (det gør den), skal I kunne vise, at I har styr på dem.

5) CRA kræver, at produktteams bygger sikkerhed ind fra start

Hvis I udvikler software/produkter:

Secure coding bliver standard, ikke “nice to have”
Sårbarheder skal håndteres systematisk
Der skal være patch/updatestrategi
Dokumentation bliver en del af leverancen

Det mest irriterende ved CRA er også det mest fornuftige: Det presser markedet mod færre “smid det ud og håb på det bedste”-produkter.

Den praktiske tjekliste: Sådan kommer du i gang (uden at drukne)

Her er en konkret, realistisk rækkefølge, som passer til de fleste virksomheder.

Trin 1: Find ud af om I er omfattet (og hvordan)

Kortlæg jeres sektor og services
Vurder størrelse og rolle i værdikæden
Tal med juridisk/compliance eller en rådgiver, hvis der er tvivl

Men vent ikke på perfekt afklaring. Hvis I leverer IT/digitale services til andre, er det klogt at starte alligevel.

Trin 2: Kortlæg “crown jewels”

Lav en enkel oversigt over:

De 10 vigtigste systemer
Kritiske data (kundedata, betalingsdata, IP, driftssystemer)
Afhængigheder (cloud, tredjepart, integrationer)

Du kan ikke beskytte alt lige meget. Prioritering er hele pointen.

Trin 3: Etabler minimum governance

Udpeg sikkerhedsansvarlig (ikke nødvendigvis CISO, men ansvar skal være tydeligt)
Definér roller: hvem ejer risiko, hvem godkender, hvem udfører
Lav en simpel sikkerhedspolitik og et risikoregister (kan starte i et dokument)

Trin 4: Byg incident response, der kan eksekveres

Mindstekrav i praksis:

Kontaktliste (internt + eksternt)
Beslutningsflow (hvornår eskalerer vi?)
Kommunikationsplan (kunder, myndigheder, presse)
Logning og bevisindsamling (så I kan forstå hvad der skete)

Trin 5: Stram adgang og identitet

Det lyder kedeligt. Det virker.

MFA på alt vigtigt
Princip om mindst mulige rettigheder
Adgangsreviews (fx kvartalsvis)
Offboarding-proces, der ikke tager 3 uger

Trin 6: Leverandørstyring light

Start simpelt:

Hvem behandler data for jer?
Hvem kan påvirke drift?
Hvilke minimumskrav har I (MFA, logging, backup, respons-tider)?
Har I kontraktuelle krav og mulighed for at få indsigt?

Trin 7: Hvis I bygger produkter: indfør CRA-klar praksis

For produktteams:

Threat modeling på centrale flows
Secure coding guidelines + code review
Dependency management (SCA), patch-rytme
Sårbarhedsproces: intake, triage, fix, release, dokumentation
“Secure by default” konfigurationer

Hvis du vil have et samlet overblik over hvordan CRA og NIS2 typisk hænger sammen i praksis (og hvad der oftest kræves af virksomheder), kan du tage udgangspunkt i denne gennemgang: Cyber Resilience Act og NIS2

Typiske faldgruber (som virksomheder elsker at træde i)

“Vi er for små”

Du kan være “for lille” til at være direkte omfattet, men stadig være leverandør til nogen der er. Og så bliver du mødt med krav alligevel.

“Vi køber os ud af det”

Du kan outsource drift. Du kan ikke outsource ansvar. Myndigheder og kunder forventer styring, dokumentation og beslutningsevne.

“Vi laver en stor compliance-rapport”

Dokumentation er vigtig, men den skal koble til virkeligheden:

Hvilke kontroller har I?
Hvad er status?
Hvad er planen?
Hvem er ansvarlig?

Ellers er det bare en dyr roman, ingen læser.

“Vi fik en pentest, så nu er vi sikre”

Pentest er et snapshot. NIS2/CRA handler om processer: løbende risikostyring, forbedringer og sårbarhedshåndtering.

Hvad skal du kunne vise til kunder, ledelse og måske myndigheder?

Hvis du vil være pragmatisk: sigt efter at kunne fremvise følgende uden at rødme.

En kort risikovurdering og et risikoregister
En oversigt over kritiske systemer og data
Incident response plan + bevis for øvelse/test
MFA, adgangsstyring og logging på kritiske systemer
Backup/restore-test (ja, testet. Ikke “vi tror”)
Leverandøroversigt og minimumskrav
For produkter: sårbarhedsproces og patch-strategi

Det er ikke glamourøst. Det er bare sådan man undgår at få hele forretningen smadret af et eller andet dumt klik på en falsk faktura.

Hvorfor det også er en mulighed (desværre)

Der er en grund til, at mange virksomheder ender med at bruge compliance som salgsargument. Når I faktisk har styr på basen:

I vinder flere B2B-aftaler
I kan lukke security questionnaires hurtigere
I sænker risikoen for driftstop og datalæk
I bliver mere robuste i leverandørkæden

Det er ikke spændende. Det er bare den slags “voksne ting”, som gør, at virksomheden stadig findes om 2 år.

Konklusion: Start småt, men start rigtigt

NIS2 og CRA er ikke en “engangsopgave”. Det er et skifte: fra ad hoc-sikkerhed til styret, dokumenterbar cybersikkerhed.

Hvis du kun gør én ting i denne uge, så gør det her:

Kortlæg jeres vigtigste systemer og data
Sæt ansvar og minimum processer
Få incident response på plads
Stram adgang og leverandører
Hvis I bygger produkter: gør sårbarhedshåndtering til en fast rutine

Det er ikke magi. Det er bare disciplin. Som mennesker åbenbart konstant skal mindes om.