Fundet om sikkerhed, der kommer for sent ind, betyder, at sikkerhedskravene først bliver stillet, når et system er købt, udviklet eller næsten klar til drift. Så er de dyre at indfri, og de bliver ofte udskudt til efter idriftsættelsen. En vurdering leder efter de steder i projektmodellen, hvor sikkerheden skulle have været med, og efter projekter i de enkelte selskaber, der er gennemført uden om koncernens model.
Det er sitets vurdering, at fundet i koncerner ofte handler mindre om modellen og mere om, hvem der følger den. Koncernen har en god projektmodel, men datterselskaberne bruger den ikke.
Sådan ser fundet ud
Fundet viser sig, når en vurdering gennemgår et udvalg af nyere projekter og ændringer og spørger, hvornår sikkerheden kom ind. Typiske svar er: da systemet skulle i drift, da revisor spurgte, eller da en hændelse viste et hul. Sjældent er svaret: da kravene blev skrevet.
I en koncern kommer et ekstra lag til. Projekter, der gennemføres i et enkelt selskab, fx et lokalt system købt af forretningen, går ofte uden om koncernens projektmodel. Koncernens sikkerhedsfunktion får aldrig at vide, at projektet findes, før systemet er i drift.
Hvad målestokkene siger
I bilaget til forordning 2024/2690 hører analysen af sikkerhedskrav hjemme i specifikations- og udformningsfasen af ethvert udviklings- eller erhvervelsesprojekt (punkt 6.2.2, litra a). Efter punkt 6.4.2 skal ændringer dokumenteres, testes og vurderes ud fra risikovurderingen, inden de gennemføres, og efter punkt 6.4.3 skal nødændringer dokumenteres med begrundelse. Forordningen binder alene de digitale tjenester i artikel 1. Som målestok for andre placerer den sikkerheden i begyndelsen af projektet og før ændringen, ikke bagefter.
For finansielle enheder går den delegerede forordning 2024/1774 længere. Artikel 15 kræver en politik for IKT-projektstyring med bl.a. risikovurdering af projekter, krav til styring af ændringer og test af alle krav, herunder sikkerhedskrav, før ibrugtagning. Projekter med indvirkning på kritiske eller vigtige funktioner skal indberettes til ledelsesorganet. Artikel 16 kræver en politik for anskaffelse, udvikling og vedligeholdelse med krav til IKT-sikkerhed og godkendelse fra forretningsfunktionen og aktivets ejer. Det gælder kun den finansielle sektor, men kravet om at indberette projekter, der berører kritiske funktioner, til ledelsen er et nyttigt forbillede.
Blandt minimumsforanstaltningerne i NIS 2-lovens § 6, stk. 1, står som nummer 5 sikkerhed ved erhvervelse, udvikling og vedligeholdelse.
Kontrolpunkterne, en vurdering leder efter
Det er praksis at lede efter en række faste kontrolpunkter i projektmodellen:
- Idé og forretningssag · Er sikkerheden nævnt, og er projektet vurderet for risiko?
- Krav og udformning · Er der skrevet sikkerhedskrav, og har nogen med sikkerhedsviden godkendt dem?
- Indkøb · Stiller kontrakten krav om sikkerhed og opdateringer i hele levetiden?
- Test · Er sikkerhedskravene testet før idriftsættelse?
- Idriftsættelse · Har aktivets ejer godkendt, og er åbne punkter registreret som risici?
- Ændringer · Bliver ændringer i drift vurderet og testet, før de gennemføres?
Kontrolpunkterne er sitets opstilling. Den tekniske kontrol af ændringsstyring og test er et emne for sig. Gennemgangen af projektmodellen i et enkelt selskab er en del af den almene auditmetode.
Projekter uden om koncernens model
I en koncern er det mindst lige så vigtigt at finde de projekter, der ikke er gået gennem modellen. Det er praksis at sammenligne koncernens projektportefølje med selskabernes indkøb af IT-systemer og -tjenester i samme periode. Systemer, der er købt, men aldrig har været et projekt i koncernens model, er de steder, hvor sikkerheden med størst sandsynlighed ikke har været med.
Fundet hænger tæt sammen med skygge-IT, som er beskrevet i skygge-IT i forretningsenhederne.
Hvem i koncernen skal sige god for et projekt?
En projektmodel med kontrolpunkter er kun så stærk som de mennesker, der skal godkende ved hvert punkt. Det er praksis at aftale, hvornår koncernens sikkerhedsfunktion skal inddrages, og hvornår det lokale selskab selv kan godkende. Et lille projekt i ét selskab kræver sjældent koncernens blik. Et projekt, der berører en fælles tjeneste, koncernens kunder eller en kritisk forretningsproces, gør. Uden en sådan grænse ender sikkerhedsfunktionen enten med at blive spurgt om alt eller om intet.
Fundet og scoren
En modenhedsmåling, der spørger, om der findes en projektmodel med sikkerhed, vil ofte give en høj score, fordi modellen findes. Fundet ligger i, hvor mange projekter der følger den. Målingen bør efter sitets opfattelse tage en stikprøve af faktiske projekter i hvert selskab og ikke nøjes med at se på modellen.
Et tænkt eksempel
Tænk jer et datterselskab, hvor salgsafdelingen køber en ny tjeneste til kundedata uden om IT, fordi den kan tages i brug med det samme. Tjenesten bliver koblet til selskabets kundesystem af en konsulent. Koncernens sikkerhedsfunktion hører først om den, da en kunde spørger, hvor deres data ligger. På det tidspunkt er tjenesten i fuld drift, og ingen har stillet krav om adgangsstyring, logning eller sletning. Eksemplet er tænkt, men det viser, hvorfor en vurdering ser på indkøbene ved siden af projektporteføljen.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at koncernens projektmodel har faste kontrolpunkter for sikkerhed, at datterselskaberne kender og bruger den, og at der er en vej for lokale indkøb ind i modellen. Det kræver også, at nogen med sikkerhedsviden har tid til at deltage i projekterne tidligt.
Lader man det være, kommer sikkerheden ind til sidst, når kravene er dyre at indfri. De bliver udskudt, og systemet går i drift med kendte huller, som ingen har accepteret formelt.
Det skal I lade være med
- At måle modellen i stedet for brugen af den · stikprøven af projekter viser virkeligheden.
- At lade lokale indkøb gå uden om modellen · det er dér, sikkerheden mangler.
- At sætte systemer i drift med åbne sikkerhedspunkter uden registrering · de bliver glemt.
Det skal gennemgangen kunne vise
- ☐ En projektmodel med faste kontrolpunkter for sikkerhed.
- ☐ En stikprøve af nyere projekter med spor af, hvornår sikkerheden kom ind.
- ☐ En sammenligning af projektporteføljen med selskabernes IT-indkøb.
- ☐ Registrerede risici for åbne sikkerhedspunkter ved idriftsættelse.
Kilder
- Gennemførelsesforordning (EU) 2024/2690, artikel 1 og bilagets punkt 6.2.2 og 6.4, læst 14. november 2026.
- Delegeret forordning (EU) 2024/1774, artikel 15 og 16, læst 14. november 2026.
- Lov nr. 434 af 6. maj 2025 (NIS 2-loven), § 6, stk. 1, nr. 5, læst 14. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Vælg fem systemer, der er sat i drift det seneste år, og find ud af, hvornår sikkerheden kom ind i hvert af dem.
Læs også: Koncernpolitik og lokal praksis · Datterselskaber med egen IT
→ Kontakt · Tlf. 70 13 63 23 · Sikkerhedsmodenhed hos Nielco IT
