Der er få ting, der kan få et ledelsesmøde til at kigge tomt ud i luften som tre EU-forkortelser på én gang. CRA, NIS2 og DORA lyder som noget, man bestiller på en italiensk café. I virkeligheden handler de om cyber- og operationel modstandskraft, krav til sikkerhed og dokumentation, og hvem der får et kæmpe problem, hvis noget går galt.
Det tricky er, at de overlapper på nogle områder, men rammer forskellige typer virksomheder og produkter. Så hvis du vil gøre det rigtigt (og ikke bare lave “compliance-teater”), skal du forstå:
- Hvad hver regulering faktisk handler om
- Hvor de overlapper (så du kan genbruge arbejdet)
- Hvordan du prioriterer, hvis du kun kan starte ét sted
Her får du en praktisk, struktureret guide til forskelle, overlap og en realistisk startplan.
Først: kort fortalt hvad de tre reguleringer er
CRA: Cyber Resilience Act
CRA handler primært om produkter med digitale elementer. Altså hardware/software, der kan forbindes og dermed kan indeholde sårbarheder. Fokus er på, at produkter skal være “secure by design”, have sårbarhedshåndtering og opdateringer, og at sikkerhed bliver en del af produktets livscyklus.
Nøgleord: produktkrav, sikker udvikling, sårbarheder, patching, leverandøransvar.
NIS2: Network and Information Security Directive 2
NIS2 handler om organisationer og deres evne til at beskytte netværk og informationssystemer. Det er bredere og går på governance, risikostyring, hændelseshåndtering, leverandører, beredskab, awareness og rapportering.
Nøgleord: organisation, governance, risiko, incident response, leverandørstyring, rapporteringskrav.
DORA: Digital Operational Resilience Act
DORA handler specifikt om finanssektoren (og visse IT-leverandører til finans). Fokus er operationel robusthed: evnen til at modstå, reagere på og komme sig efter IT- og cyberhændelser. Den går dybt med test, tredjepartsrisiko, krav til hændelser og styring.
Nøgleord: finans, driftsrobusthed, test/øvelser, tredjeparts-IKT, incident management.
Hvem gælder hvad for?
Det vigtigste spørgsmål er ikke “hvad betyder forkortelsen”. Det er: rammer den mig?
CRA rammer typisk dig hvis…
- du udvikler eller sælger software/hardware som produkt
- du leverer IoT, apps, platforme, plugins, enheder, softwarekomponenter
- du er producent, importør eller distributør af digitale produkter
CRA kan også indirekte ramme virksomheder, der køber produkter, fordi de i stigende grad vil kræve dokumentation fra leverandører.
NIS2 rammer typisk dig hvis…
- du er i en sektor, der klassificeres som essentiel eller vigtig (energi, transport, sundhed, digital infrastruktur, offentlige tjenester, m.m.)
- du leverer kritiske ydelser eller er i en værdikæde, hvor du bliver “presset” af krav fra kunder
- du har en vis størrelse/rolle, der bringer dig ind under kravene (det afhænger af national implementering og sektor)
DORA rammer typisk dig hvis…
- du er finansiel virksomhed (bank, forsikring, investeringsvirksomhed osv.)
- eller du er IKT-tredjepartsleverandør til finanssektoren, hvor DORA’s krav kan “trickle down” via kontrakter, audits og krav til kontroller.
De største forskelle i praksis
Her er den praktiske “hvad betyder det for mig”-forskel:
1) Produkt vs. organisation
- CRA: “Dit produkt skal være sikkert og vedligeholdes sikkert.”
- NIS2: “Din organisation skal have styring og kontroller, der reducerer risiko.”
- DORA: “Din drift og leverandørkæde skal kunne modstå og komme sig efter hændelser, og du skal kunne bevise det gennem test og governance.”
2) Compliance-tyngde
- CRA kan være tung for produktteams, fordi den kræver proces, dokumentation, patching, disclosure osv.
- NIS2 er tung for ledelse og IT/security governance.
- DORA er tung for finans, fordi den går dybt i testregimer, tredjepart og operationel robusthed.
3) Rapportering og hændelser
NIS2 og DORA har begge fokus på hændelser og rapportering. DORA er ofte mere struktureret og “driftsorienteret” i finanskontekst. NIS2 er bredere på tværs af sektorer.
Overlap: det du kan genbruge på tværs
Selvom CRA, NIS2 og DORA ikke er det samme, er der store områder, hvor du kan lave ét stykke arbejde og bruge det flere steder.
Overlap 1: Risikostyring
- Trusselsbillede
- Risikoanalyse
- Prioritering af kontroller
- Dokumentation af beslutninger
Hvis du bygger et solidt risikorammeværk, kan du genbruge det direkte i NIS2 og DORA, og indirekte støtte CRA ved at dokumentere risici i produkt og supply chain.
Overlap 2: Sårbarhedshåndtering
CRA kræver i praksis moden sårbarhedshåndtering for produkter. NIS2 og DORA kræver sårbarhedshåndtering for systemer og drift.
Én god proces kan dække:
- scanning og triage
- prioritering (CVSS + forretningskritikalitet)
- patching og change management
- dokumentation
- kommunikation/disclosure (relevant især under CRA)
Overlap 3: Incident response og beredskab
NIS2 og DORA vil have, at du kan:
- opdage hændelser hurtigt
- reagere med klare roller
- eskalere korrekt
- kommunikere internt/eksternt
- lære af hændelser
Hvis du bygger en praktisk incident runbook (med tabletop øvelser), kan den være “motoren” i begge.
Overlap 4: Leverandørstyring
Alle tre reguleringer presser i retning af bedre styring af tredjepart:
- hvilke leverandører har adgang til hvad?
- hvilke SLA’er, sikkerhedskrav og audits?
- hvordan håndterer du underleverandører?
- hvordan dokumenterer du det?
DORA er ofte mest konkret her, men NIS2 og CRA trækker samme vej.
Prioritering: hvad starter du med?
Hvis du kun kan starte ét sted, så start der, hvor du får mest “compliance-coverage” for din indsats.
Trin 1: Find din “primære” regulering
Spørg:
- Er vi finans eller leverandør til finans? → DORA er sandsynligvis primær
- Er vi i en NIS2-sektor eller leverer kritiske ydelser? → NIS2 primær
- Sælger vi digitale produkter? → CRA primær
- Rammer flere? → så bygger du en fælles baseline og tilpasser
Trin 2: Byg en baseline, der dækker overlap
Den bedste startpakke, der hjælper på tværs, er:
- Asset inventory (systemer, data, integrationer, leverandører)
- Risikovurdering (hvad kan gå galt, hvad betyder det?)
- Incident response (roller, flow, kommunikation, øvelser)
- Sårbarhedshåndtering (scan → triage → patch → dokumentér)
- Leverandørstyring (klassificér leverandører + krav + kontrakter)
Det er kedeligt. Det virker. Og det er genbrugeligt.
Trin 3: Tilføj “regulator-specifikke” lag
Når baseline er på plads, bygger du ovenpå:
- CRA-lag: secure development lifecycle, produktdokumentation, vulnerability disclosure, update policy
- NIS2-lag: ledelsesforankring, policies, awareness, rapporteringsflow, governance
- DORA-lag: testregimer, operational resilience metrics, tredjeparts-IKT detaljer, finans-krav til dokumentation
Praktisk startplan: 30-60-90 dage
Her er en realistisk plan, som en virksomhed faktisk kan gennemføre uden at gå helt i stykker.
Første 30 dage: Skab overblik og få styr på minimum
- Kortlæg kritiske systemer og data (top 20, ikke 200)
- Kortlæg leverandører med adgang til drift/data
- Definér incident roller og eskalation (RACI)
- Lav en enkel risk workshop (hvad er top 10 risici?)
- Vælg et værktøj eller format til evidens (så du kan dokumentere alt)
Output: overblik + baseline governance.
30-60 dage: Byg processerne der gentager sig
- Sårbarhedshåndtering (frekvens, ansvar, SLA for patching)
- Change management light (hvem godkender, hvordan dokumenteres)
- Incident runbook + tabletop øvelse
- Leverandørklassificering + minimumskrav i kontrakter
- Backup/restore test (ja, faktisk test)
Output: processer, der gør dig bedre, ikke bare compliant.
60-90 dage: Byg dokumentation og “compliance mapping”
- Map kontroller til CRA/NIS2/DORA (hvor dækker vi hvad?)
- Identificér gaps og prioriter top 10
- Beslut testplan og audit-evidens
- Hvis CRA relevant: formaliser secure-by-design i udviklingsflow
Output: roadmap + beviser + prioriterede gaps.
“Hvad starter jeg med?” afhænger af din type virksomhed
Her er tre typiske scenarier:
Scenario A: SaaS/Tech-virksomhed med produkt
Start med CRA-inspireret produktdisciplin:
- sårbarhedshåndtering
- patch policy
- secure development baseline (code review, dependency management, secrets)
Samtidig bygger du NIS2-lignende governance, fordi kunder vil kræve det.
Scenario B: Klassisk virksomhed i NIS2-sfære
Start med NIS2-governance:
- risiko, policies, incident response, awareness
- leverandørstyring
Du kan senere tilføje CRA-krav, hvis du også leverer digitale produkter.
Scenario C: Finans eller leverandør til finans
Start med DORA-rygraden:
- tredjeparts-IKT og kontrakter
- test og øvelser
- incident management struktur
Det er næsten altid der presset kommer først.
Typiske faldgruber (så du kan undgå dem)
1) “Vi skriver policies først”
Policies uden praksis er bare tekst. Byg proces og evidens samtidig.
2) “Vi gør det i IT”
NIS2 og DORA er ikke kun IT. Det er ledelse, drift, leverandører og forretning. Hvis ledelsen ikke ejer det, bliver det tyndt.
3) “Vi køber et værktøj og så er vi compliant”
Værktøjer hjælper, men compliance er processer + ansvar + dokumentation.
4) “Vi laver alt på én gang”
Du ender med ingenting færdigt. Lav baseline først, byg ovenpå.
En enkel beslutningsmodel til ledelsen
Hvis du skal forklare det til ledelsen på 60 sekunder:
- CRA = produktkrav (sikkerhed indbygget i det vi sælger)
- NIS2 = organisationskrav (styring og kontroller i driften)
- DORA = finansdrift (høj robusthed + test + leverandørstyring)
- Overlap = risiko, incidents, sårbarheder, leverandører
- Start = baseline + prioriteret roadmap
Hvis du vil have en mere samlet gennemgang, der binder det hele sammen med en prioriteringsvinkel, kan du bruge denne guide til CRA, NIS2 og DORA som referencepunkt, især når du skal beslutte rækkefølge og sammenhæng i arbejdet.
Konklusion: gør det smart, ikke bare “compliant”
CRA, NIS2 og DORA er forskellige, men de peger i samme retning: bedre sikkerhed, bedre governance og bedre robusthed.
Den mest effektive vej frem er:
- Afklar hvilken regulering der er primær for jer
- Byg en fælles baseline (risiko, incident, sårbarheder, leverandører)
- Tilføj regulator-specifikke krav som lag
- Dokumentér alt løbende, så du ikke skal “opfinde evidens” til sidst
Hvis du gør det sådan, får du både compliance og en organisation, der reelt er sværere at vælte. Og det er jo meget rarere end at være “compliant” på papir og kaotisk i virkeligheden.
Leave a Reply