En koncernbaseline er det gulv, ingen enhed må ligge under. Den virker kun, hvis hvert krav er formuleret, så det kan kontrolleres på samme måde i alle enheder, og hvis undtagelser bliver registreret med en ejer, en begrundelse og en udløbsdato. Uden registeret bliver baselinen til en ønskeliste.
Baselinen er også et af de mest nyttige redskaber i en modenhedsmåling. Den giver et fast punkt, som alle enheder kan måles mod, uanset hvor forskellige de ellers er.
Hvad baselinen kan bygge på
Koncernen kan formulere sine egne krav, men mange bygger på en kendt målestok. CIS Controls version 8.1 deler sine 153 safeguards i tre implementeringsgrupper. CIS beskriver den første gruppe, IG1, som “essential cyber hygiene”, som alle virksomheder bør starte med. Det var gældende version, da CIS’ side blev læst 14. november 2026. IG1 egner sig derfor godt som udgangspunkt for et fælles gulv, især i koncerner med mange små enheder.
For de selskaber, der er omfattet af NIS 2, har loven en minimumsliste over foranstaltninger (NIS 2-loven § 6, stk. 1). Listen gælder kun de omfattede enheder. Den kan bruges som inspiration til koncernens baseline, men den gør ikke kravene til lov for de øvrige selskaber.
Krav, der kan kontrolleres ens
Et baselinekrav skal kunne besvares med ja eller nej på grundlag af bevis. “Der skal være passende adgangsstyring” kan ikke kontrolleres ens. “Alle brugere med fjernadgang skal bruge totrinsgodkendelse” kan.
- Krav · (Alle administratorkonti har totrinsgodkendelse)
- Gælder for · (Alle enheder uden undtagelse)
- Bevis · (Udtræk fra identitetsløsningen med alle administratorkonti og deres godkendelsesmetode)
- Hvem kontrollerer · (Koncernens sikkerhedsfunktion ved den årlige måling)
- Henvisning · (CIS Controls 8.1, safeguard i IG1, eller koncernens egen begrundelse)
Skemaet er en skabelon, og eksemplerne i parentes er tænkte. Hold baselinen kort, og skriv for hvert krav, hvorfor det er med. En baseline med hundrede krav bliver behandlet som en modenhedsmodel, og så mister den sin funktion som gulv.
Dispensationsregisteret
Ikke alle enheder kan opfylde alle krav med det samme. En fabrik kan have en styring, der ikke tåler opdateringer. Et opkøbt selskab kan bruge et system, der ikke understøtter koncernens løsning. Så skal der gives en dispensation, og den skal registreres.
Et register har mindst disse felter: hvilket krav, hvilken enhed, hvorfor, hvilke kompenserende tiltag der er sat i værk, hvem der har godkendt, og hvornår dispensationen udløber. Udløbsdatoen er det vigtigste felt. En dispensation uden udløb er en permanent undtagelse, som ingen har besluttet.
Registerets form og felter er praksis. Ingen regel uden for finans fastlægger dem. Gennemgå registeret mindst en gang om året.
Hvem må give dispensation?
Det afhænger af koncernens risikostyring. En dispensation er i realiteten en accept af en risiko, og den bør gives af en person, som må acceptere den slags risiko. I en koncern vil det ofte være enhedens direktør for mindre risici og koncernledelsen for større.
I finanssektoren lægger DORA fastsættelsen af risikotolerance for IKT-risici hos ledelsesorganet (art. 5, stk. 2, litra d). Det gælder kun finansielle enheder, men tankegangen kan overføres: rammen for, hvor meget der må accepteres, sættes øverst.
Ifølge IIA’s Global Internal Audit Standards er det revisionschefen, der tager stilling til, om en handlingsplan, der trækker ud, i praksis betyder, at direktionen har accepteret en risiko ud over tolerancen (standard 15.2). En dispensation, der udløber uden at blive fornyet eller lukket, er netop sådan en situation.
Når baselinen skal ændres
Baselinen er ikke skrevet én gang for alle. Nye trusler, nye krav fra kunder eller myndigheder og erfaringer fra hændelser kan gøre et nyt krav nødvendigt. Et krav kan også blive overflødigt, fordi en fælles løsning har gjort det selvfølgeligt.
Ændres baselinen, skal enhederne have tid til at nå det nye gulv, og ændringen skal stå i målingens ændringslog. Et nyt krav, der indføres midt i en måleperiode, får ellers alle enheder til at se svagere ud, uden at noget er blevet dårligere. En fast årlig revision af baselinen, med en frist for hvornår nye krav skal være opfyldt, giver ro omkring det.
Baselinen i målingen
I modenhedsmålingen kan baselinen vises for sig: hvor mange krav hver enhed opfylder, og hvor mange dispensationer den har. Det giver bestyrelsen et enkelt billede af gulvet, adskilt fra den samlede modenhed. En enhed kan have en høj modenhed på mange områder og alligevel ligge under gulvet på ét krav.
Hvordan de tekniske krav i en baseline efterprøves på systemniveau, beskrives under de tekniske kontrolpunkter.
Hvad det kræver, og hvad det koster at lade være
Det kræver en kort liste af kontrollerbare krav, en klar regel for, hvem der må give dispensation, og et register, som nogen gennemgår, før dispensationerne udløber. Det kræver også, at baselinen bliver revideret, når trusselsbilledet eller koncernen ændrer sig.
Uden baseline og register ved koncernen ikke, om alle enheder står på samme gulv. Dispensationer givet i en travl periode bliver liggende i årevis, og ingen kan sige, hvem der har accepteret risikoen.
Det skal I lade være med
- At formulere krav, der ikke kan kontrolleres ens · så bliver gulvet forskelligt fra enhed til enhed.
- At give dispensationer uden udløbsdato · de bliver permanente uden beslutning.
- At gøre baselinen så lang, at den ligner en modenhedsmodel · den skal være et gulv.
Det skal gennemgangen kunne vise
- ☐ En baseline med kontrollerbare krav og angivet bevis for hvert.
- ☐ Et dispensationsregister med begrundelse, kompenserende tiltag, godkender og udløbsdato.
- ☐ En regel for, hvem der må godkende dispensationer.
- ☐ Status pr. enhed for opfyldte krav og aktive dispensationer.
Kilder
- Center for Internet Security, CIS Critical Security Controls Implementation Groups, læst 14. november 2026.
- Lov nr. 434 af 6. maj 2025 (NIS 2-loven), § 6, stk. 1, læst 14. november 2026.
- Forordning (EU) 2022/2554 (DORA), art. 5, stk. 2, litra d, læst 14. november 2026.
- The Institute of Internal Auditors, Global Internal Audit Standards, 2024, standard 15.2, læst 14. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Gennemgå jeres aktive undtagelser og find dem uden udløbsdato. De er det første, der skal tages stilling til.
Læs også: Små enheder i en stor koncern · CIS Controls v8.1 og implementeringsgrupperne
→ Kontakt · Tlf. 70 13 63 23 · Sikkerhedsmodenhed hos Nielco IT
