Et website, en webshop eller et intranet er ikke længere blot en kommunikationskanal. Det er en del af virksomhedens digitale infrastruktur, ofte med adgang til kundedata, betalingsflow, integrationsplatforme og interne arbejdsgange. Derfor får EU regler for cyberrobusthed direkte betydning for, hvordan digitale løsninger vælges, udvikles, driftes og vedligeholdes.
For mange danske organisationer er udfordringen ikke at læse lovteksten. Udfordringen er at omsætte kravene til konkrete beslutninger: Hvem har ansvar for opdateringer? Hvor ligger data og logfiler? Kan en sikkerhedshændelse opdages og håndteres hurtigt? Og er leverandørkæden dokumenteret hele vejen?
EU regler for cyberrobusthed rammer bredere end IT-afdelingen
EU skærper cybersikkerheden gennem flere regelsæt, der har forskellige formål og målgrupper. De mest centrale er NIS2-direktivet, Cyber Resilience Act og i visse brancher DORA. Samtidig består GDPR-kravene, når personoplysninger behandles. Reglerne overlapper på flere punkter, men de er ikke det samme.
NIS2 handler især om organisationers evne til at forebygge, håndtere og rapportere cyberhændelser. Direktivet retter sig mod udvalgte sektorer og virksomheder af en vis størrelse eller samfundsmæssig betydning. En almindelig mindre virksomhed med et website er ikke automatisk omfattet. Men hvis virksomheden leverer kritiske eller væsentlige tjenester, indgår i en kritisk leverandørkæde eller har en størrelse, der falder inden for reglerne, kan kravene være relevante.
Cyber Resilience Act retter sig derimod mod produkter med digitale elementer, der bringes på markedet i EU. Det kan omfatte software, hardware og kommercielle komponenter. For leverandører af digitale produkter betyder det blandt andet krav om sikkerhed gennem produktets levetid, håndtering af sårbarheder og teknisk dokumentation. Reglerne indfases over tid, og det er afgørende at kende de konkrete frister for den rolle, virksomheden har.
DORA gælder den finansielle sektor og en række af dens kritiske IT-leverandører. Her er kravene til operationel digital modstandsdygtighed særligt detaljerede. Hvis en webshop eksempelvis blot tager imod kortbetalinger via en betalingsudbyder, er den ikke nødvendigvis omfattet af DORA. Men finansielle virksomheder og deres teknologipartnere skal forholde sig til et helt andet kontrolniveau.
Det afgørende spørgsmål er ikke kun, om I er omfattet
Mange fokuserer forståeligt nok på, om en konkret lov gælder direkte for deres virksomhed. Det er relevant, men ikke tilstrækkeligt. Kunder, offentlige indkøbere, forsikringsselskaber og større samarbejdspartnere stiller i stigende grad krav, der afspejler EU-reglerne – også til leverandører, som ikke selv er direkte omfattet.
En virksomhed kan derfor møde krav om dokumenterede backup-rutiner, adgangsstyring, beredskabsplaner, patch management og underleverandørstyring i et udbud eller en kontrakt. I praksis bliver cybersikkerhed en del af kvalifikationen for at levere digitale løsninger, ikke alene et juridisk spørgsmål.
Det gælder særligt, når website, webshop, app eller intranet er tæt koblet til forretningskritiske systemer. En kompromitteret formular kan give adgang til personoplysninger. En sårbar integration kan påvirke ordreflowet. En manglende opdatering kan åbne for misbrug af en ellers velfungerende platform.
NIS2: Ledelsen skal kunne tage ansvar
NIS2 flytter cybersikkerhed tydeligere op på ledelsesniveau. Det betyder ikke, at direktionen skal kunne gennemgå serverlogs eller vurdere kodekvalitet. Men ledelsen skal kunne sikre, at der findes passende risikostyring, klare roller og et grundlag for at træffe oplyste beslutninger.
For digitale løsninger bør det føre til helt praktiske afklaringer. Hvem ejer platformen? Hvem må ændre i produktion? Hvem modtager sikkerhedsadvarsler? Hvor hurtigt installeres kritiske sikkerhedsopdateringer? Og hvad gør organisationen, hvis en vigtig integration eller loginløsning fejler?
Et godt sikkerhedsniveau opstår ikke ved at købe ét produkt eller gennemføre én årlig scanning. Det opstår gennem en driftsmodel, hvor opdateringer, overvågning, backup, adgang og hændelseshåndtering er aftalt, udført og dokumenteret løbende.
Leverandørkæden skal kunne forklares
NIS2 lægger vægt på risici i forsyningskæden. For en digital platform betyder det, at man skal kende mere end den nærmeste udviklingspartner. Hosting, DNS, mail, CDN, analyseværktøjer, betalingsløsninger, plugins og eksterne integrationer kan alle påvirke sikkerheden.
Det er ikke realistisk at fjerne enhver afhængighed. Men det er realistisk at vælge en arkitektur, hvor afhængighederne er synlige, velbegrundede og begrænsede. En løsning med åbne standarder og dokumenterede grænseflader er ofte lettere at flytte, revidere og genoprette end en løsning, hvor centrale funktioner er bundet til én lukket platform.
EU-baseret hosting og en fuld EU-databehandlerkæde løser heller ikke alle sikkerhedsopgaver. Det gør derimod dataplacering, kontraktforhold og tilsyn enklere at gennemskue – og reducerer afhængigheden af jurisdiktioner uden for EU. Det er et strategisk valg, ikke en erstatning for god drift.
Cyber Resilience Act ændrer forventningerne til software
Cyber Resilience Act gør sikkerhed til et produktansvar for virksomheder, der udvikler eller markedsfører berørte digitale produkter. I praksis betyder det, at sikkerhed ikke må være et punkt, der tilføjes efter lanceringen. Producenten skal kunne arbejde systematisk med risikovurdering, sårbarhedshåndtering, sikkerhedsopdateringer og dokumentation.
For organisationer, der får udviklet specialfunktioner til en platform, er rollefordelingen væsentlig. Er løsningen et internt værktøj, en kundevendt service eller et produkt, der distribueres til andre? Er den byggede komponent baseret på tredjepartskode? Og hvem har ansvar for at vedligeholde den, når den er i drift?
Open source kræver også omtanke. Open source er ikke i sig selv mindre sikkert – ofte tværtimod, fordi koden kan granskes, og løsningen kan flyttes. Men komponenter skal holdes opdaterede, licenser skal forstås, og der skal være en klar proces for at reagere på kendte sårbarheder. En platform med 40 ubemandede plugins er ikke en forsvarlig driftsstrategi, uanset hvor moderne designet er.
Fra compliance-projekt til driftsdisciplin
Den mest effektive måde at arbejde med kravene på er at tage udgangspunkt i den konkrete platform og dens risici. Et lokalt informationssite uden login har et andet behov end en webshop med kundekonti, ERP-integration og persondata. Et intranet med følsomme HR-dokumenter kræver noget andet igen.
Start med at kortlægge, hvilke data, systemer og leverandører løsningen afhænger af. Dernæst bør I prioritere de kontroller, der reducerer størst risiko: stærk adgangsstyring, multifaktorlogin for administratorer, løbende opdateringer, testede backups, segmenterede rettigheder og logning af væsentlige hændelser.
Derudover skal beredskabet være brugbart. En beredskabsplan på 40 sider hjælper ikke meget klokken 07.15, når webshoppen er nede. Teamet skal vide, hvem der beslutter, hvem der undersøger, hvem der kommunikerer, og hvordan løsningen kan gendannes. Den plan bør testes i praksis, også når driften ellers kører stabilt.
Netkant arbejder med sikkerhed som en integreret del af udvikling og drift, fordi det er dér, kravene bliver til reel risikoreduktion. Det gælder blandt andet valg af hosting, opdateringsrutiner, adgangsmodeller, backup og dokumentation af den tekniske løsning.
Sikkerhed skal kunne vedligeholdes
Det er let at vælge en løsning, der ser korrekt ud ved lancering. Det svære er at sikre, at den stadig er forsvarlig om to eller fem år, når medarbejdere skifter, integrationer ændres, og nye sårbarheder opstår.
Derfor bør den næste samtale om jeres digitale platform ikke kun handle om funktioner, design og pris. Spørg også, hvordan løsningen opdateres, hvem der har adgang, hvor data befinder sig, og hvordan I kommer videre, hvis leverandørforholdet ændrer sig. Det er her, cyberrobusthed bliver en konkret forretningsbeslutning.
