I et softwarehus er der to sikkerhedsopgaver, som let bliver til én i hovedet på ledelsen. Den ene er produktets sikkerhed, altså det, kunderne køber og bruger. Den anden er virksomhedens sikkerhed, altså medarbejdernes konti, udviklernes adgange, leverandørerne, beredskabet og ledelsens tilsyn. Teknisk ledelse ejer som regel den første. Den anden ejer ofte ingen, fordi alle går ud fra, at dygtige udviklere har styr på det. Artiklen viser, hvor grænsen går, hvilke regler der rammer hvad, og hvordan ledelsen får ét svar til kunden.
To opgaver med hver sin ejer
Produktets sikkerhed handler om, hvordan koden bliver til, hvordan sårbarheder rettes, og hvad kunden kan regne med. Den hører hjemme hos den, der leder udviklingen, typisk en CTO.
Virksomhedens sikkerhed handler om alt det, som produktet står på. Hvem kan komme ind i kildekoden, cloudkontoen og supportværktøjet? Hvad sker der, når en udvikler stopper? Må en konsulent få adgang til kundedata? Er der en plan, hvis mailen er overtaget? Det er sikkerhedsledelse, og den rolle kan en ekstern CISO have.
En tænkt situation viser forskellen. Koden i et softwarehus med 35 ansatte er gennemtestet, men en supportmedarbejder har en adgang til produktionsdata, ingen har gennemgået i to år. Produktet er i orden, og virksomheden er åben.
I et mindre softwarehus er det ofte den samme person, der har begge kasketter. Det kan være rimeligt længe, men så bedømmer den, der bygger, sit eget byggeri. Ledelsen bør vide, at det er et valg. Hvornår én person kan dække to roller, er vejet i artiklen om én ekstern i flere roller.
Reglerne følger samme linje
NIS2 ser på virksomheden. Loven gælder enheder i bestemte sektorer, og den digitale sektor er blandt dem. Udbydere af cloudcomputingtjenester og administrerede tjenester er omfattet under størrelsesgrænserne, og Digitaliseringsstyrelsen er kompetent myndighed. Om en SaaS er en cloudcomputingtjeneste, afhænger af definitionen i lovens § 3, og Digitaliseringsstyrelsens side nævner ikke SaaS direkte. Svaret kan altså være ja, og det skal vurderes konkret. Er svaret ja, gælder registrering, foranstaltninger, underretning og ledelsens godkendelse, og loven har en særlig registreringsbestemmelse for digitale udbydere i § 9.
Cyber Resilience Act ser på produktet. Forordningen om cyberrobusthed stiller krav til produkter med digitale elementer. Meldepligten for aktivt udnyttede sårbarheder og alvorlige hændelser begyndte 11. september 2026. Hovedkravene følger 11. december 2027. Kommissionens vejledning, som ikke er bindende, skelner mellem software, der kører hos brugeren, og en webapplikation, som brugeren kun åbner i browseren. Den grænse skal teknisk ledelse afklare, gerne med en advokat.
Kunderne ser på begge dele. Også et softwarehus uden for NIS2 kan få kravene via kundernes kontrakter, se sikkerhedskrav i kundekontrakten. Kundernes spørgsmål går på tværs af produkt og virksomhed.
Reglerne er forskellige, men de samme mennesker skal svare, og én hændelse i produktet kan udløse både pligter efter CRA og, hvis I er omfattet, NIS2 og besked til kunderne. Derfor skal fristerne stå samlet i beredskabsplanen. Fristerne efter NIS2 og for persondata står på frister i sikkerhedsarbejdet.
Hvem ejer hvad
En fordeling, der kan bruges som udgangspunkt:
- Teknisk ledelse ejer kodegennemgang, afhængigheder, sårbarheder i produktet, rettelser og produktets svar på tekniske spørgsmål.
- Sikkerhedsledelsen ejer risikovurdering, politikker, adgangsprincipper, leverandørkrav, medarbejdernes regler, beredskabet som helhed og rapporten til ledelsen.
- Direktionen ejer prioriteringen, når sikkerhed og levering af funktioner står over for hinanden, og godkendelsen efter § 7, hvis I er omfattet.
Fire ting går på tværs og skal have en navngiven ejer:
- Udviklernes adgange. Hvem kan skrive til produktionen, og hvem har gennemgået det?
- Hændelser. Hvem beslutter, om en fejl i produktet er en sikkerhedshændelse?
- Leverandører. Cloud, kodeværktøjer og underleverandører skal stå på samme leverandøroversigt.
- Kundens spørgsmål. Hvem samler svaret?
Kunden skal have ét svar
Sikkerhedsspørgeskemaet er stedet, hvor det skinner igennem. Sælgeren får det, sender det til udviklerne, og de svarer om produktet, men spørgsmålene om medarbejdere, beredskab og leverandører bliver besvaret efter bedste evne. Næste kunde får et andet svar.
Vælg én, der ejer svarene, og lad teknisk ledelse levere til produktdelen. Hvert svar er et løfte, så det skal kunne genfindes i det, I faktisk gør. Fremgangsmåden står i Kunden har sendt et sikkerhedsspørgeskema: hvem svarer?.
Fire spørgsmål til næste ledelsesmøde
- Hvem ejer virksomhedens sikkerhed i dag, ved navn?
- Har vi vurderet, om vi er omfattet af NIS2, og står begrundelsen i referatet?
- Har vi vurderet, om produktet er omfattet af CRA, og hvem holder øje med underretningen?
- Hvem kan afgøre, om en fejl i produktet skal meldes, en fredag aften?
Er det første spørgsmål uden svar, begynder I dér.
Det skal I lade være med
- At lade gode udviklere være svaret på alt · de løser produktet og sjældent virksomhedens leverandører, beredskab og rapport.
- At slå NIS2 og CRA sammen · to regelsæt med hver sit formål kræver to vurderinger.
- At svare kunder fra hukommelsen · svarene skal stemme med hinanden og med virkeligheden.
- At hente en sikkerhedsleder, der vil styre koden · rollen arbejder sammen med teknisk ledelse og overtager den ikke.
Det skal I kræve af den eksterne
- ☐ En skriftlig grænse mellem produktets og virksomhedens sikkerhed.
- ☐ Begrundede vurderinger af, hvad der skal afklares med myndighed eller advokat.
- ☐ Ét fælles beredskab, hvor produkthændelser er tænkt med.
- ☐ En samlet dokumentation til kundernes spørgsmål.
- ☐ Respekt for teknisk ledelse og ingen krav om kodearbejde.
Kilder
- Lov nr. 434 af 6. maj 2025 (NIS2-loven): § 3 om definitioner, § 7 om ledelsesorganet og § 9 om registrering af digitale udbydere.
- Digitaliseringsstyrelsen: Er I omfattet af NIS 2-loven?: den digitale sektor og de tre afklaringsspørgsmål.
- Bekendtgørelse nr. 620 af 2. juni 2025: § 6 om Digitaliseringsstyrelsen som kompetent myndighed.
- Europa-Kommissionen: Cyber Resilience Act: datoer for underretning og hovedkrav.
- Kommissionens vejledning til CRA af 27. juli 2026: grænsen for software og fjerndatabehandling. Vejledningen er ikke bindende.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Sikkerhed ved anskaffelse og udvikling af systemer · Hvilken myndighed fører tilsyn med jer?
→ Kontakt · Tlf. 70 13 63 23 · CISO as a Service hos Nielco IT
