DORA IKT-risikovillighed: vejledning til bestyrelsesgodkendelse i 2026

Klokken er 08:15 en tirsdag, og CISO’en i en mellemstor betalingsteknologivirksomhed står uden for bestyrelseslokalet med tre dokumenter åbne på en tablet.

Det første er IKT-risikoregisteret. Det har 137 rækker, farvekodede vurderinger og flere høje risici knyttet til cloudkoncentration, privilegeret adgang, genopretning efter ransomware, eksponering af kundedata og leverandørers hændelseshåndtering. Det andet er DORA-parathedsoverblikket. Det viser, at virksomheden har politikker, hændelsesprocedurer, tredjepartsregistre og planer for robusthedstest. Det tredje er bestyrelsesmaterialet til et regulatorisk møde.

Formanden har ét spørgsmål, og det er ikke teknisk:

“Hvilket niveau af IKT-risiko har vi faktisk aftalt at acceptere?”

Der bliver stille i lokalet, fordi virksomheden har risikovurderinger, men ikke en bestyrelsesgodkendt IKT-risikovillighed. Den har konsekvensvurderinger, men ikke målbare tolerancetærskler. Den har eskaleringsmøder, men ingen formel udløser, der angiver, hvornår en cyberrisiko bliver en beslutning for ledelsesorganet. Den har accepterede restrisici, men nogle begrundes som “forretningsbeslutninger” uden klar forbindelse til risikokriterier, proportionalitet efter GDPR Article 32, DORA’s forventninger til tolerance eller NIS2’s ledelsesansvar.

Denne mangel bliver stadig tydeligere i 2026. DORA finder anvendelse fra 17. januar 2025 og kræver, at finansielle enheder opretholder en styrings- og kontrolramme for IKT-risiko, herunder ledelsesorganets ansvar for IKT-risikostyringsrammen, strategien for digital operationel robusthed og IKT-risikotolerance. NIS2 presser ledelsesorganer til at godkende foranstaltninger til styring af cybersikkerhedsrisici og føre tilsyn med implementeringen. GDPR Article 32 kræver passende tekniske og organisatoriske sikkerhedsforanstaltninger baseret på risiko. ISO/IEC 27001:2022 giver ledelsessystemets mekanik: kontekst, interessenter, risikokriterier, behandlingsplaner, dokumenteret information og ledelsens gennemgang.

Den manglende bro er en erklæring om IKT-risikovillighed og IKT-risikotolerance, som en bestyrelse kan forstå, godkende, udfordre og anvende.

Denne vejledning forklarer, hvordan broen bygges ved hjælp af Clarysecs Zenith Blueprint: En revisors 30-trins køreplan, Clarysecs Politik for risikostyring, Clarysecs Politik for risikostyring for SMV’er og Zenith Controls: Vejledningen til tværgående efterlevelse.

Hvorfor risikoregistre ikke er risikovillighed

Mange organisationer forveksler et risikoregister med risikostyring på ledelsesniveau. Et risikoregister fortæller, hvilke risici der findes, hvordan de er vurderet, hvem der ejer dem, og hvilken behandling der er planlagt. Det besvarer ikke automatisk de spørgsmål på bestyrelsesniveau, som DORA, NIS2, GDPR og ISO/IEC 27001:2022 forventer, at ledere adresserer.

En moden erklæring om IKT-risikovillighed besvarer spørgsmål som:

• Hvilke IKT-risici er uacceptable uanset omkostning?
• Hvilken driftsmæssig nedetid kan forretningen tolerere for en kritisk eller vigtig funktion?
• Hvilket niveau af datatab eller kompromittering af dataintegritet ligger uden for risikovilligheden?
• Hvilken tredjepartskoncentrationsrisiko kræver bestyrelsens opmærksomhed?
• Hvem må acceptere IKT-restrisiko, og på hvilket niveau?
• Hvornår skal en risiko eskaleres til øverste ledelse eller ledelsesorganet?
• Hvordan indarbejdes juridiske, regulatoriske og kontraktlige krav i risikokriterier?

Under DORA er dette ikke valgfri governance-polering. Article 5 kræver, at ledelsesorganet definerer, godkender, fører tilsyn med og er ansvarligt for IKT-risikostyringsrammen, herunder strategien for digital operationel robusthed og IKT-risikotolerance. Article 6 kræver en dokumenteret IKT-risikostyringsramme, årlig gennemgang for ikke-mikrovirksomheder, intern revision, afhjælpning af kritiske revisionskonstateringer og en strategi for digital operationel robusthed med IKT-mål, risikotolerance, konsekvenstolerance, arkitektur, test og strategi for hændelseskommunikation.

NIS2 tilføjer en parallel ansvarlighedsmodel. Article 20 kræver, at ledelsesorganer i væsentlige og vigtige enheder godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og modtager træning. Article 21 kræver passende og proportionale tekniske, operationelle og organisatoriske foranstaltninger baseret på en all-hazards-tilgang, herunder risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker udvikling, kontroleffektivitet, træning, kryptografi, HR-sikkerhed, adgangsstyring, politik for aktivstyring og MFA, hvor det er relevant.

For finansielle enheder behandles DORA som en sektorspecifik EU-retsakt, hvor overlappende NIS2-forpligtelser finder anvendelse. I praksis fortrænger DORA generelt overlappende NIS2-krav til risikostyring og hændelsesrapportering for finansielle enheder inden for sit anvendelsesområde, mens NIS2 fortsat er vigtig for koordinering og for udbydere uden for DORA’s direkte forpligtelser for finansielle enheder. For SaaS-, cloud-, udbydere af administrerede tjenester og udbydere af administrerede sikkerhedstjenester kan NIS2 finde direkte anvendelse, når omfangsbetingelserne er opfyldt.

Derfor er bestyrelsesgodkendt IKT-risikovillighed ikke længere blot et finansielt risikodokument. Det er en governance-kontrol for cybersikkerhed.

Brug ISO/IEC 27001:2022 som operativt system

DORA og NIS2 fortæller ledere, hvad der skal styres. ISO/IEC 27001:2022 giver organisationer et praktisk operativt system for, hvordan det skal styres.

ISO/IEC 27001:2022 punkt 4.1 til 4.4 kræver, at organisationen definerer kontekst, interessenter, krav, ISMS-omfang og ISMS-processer. Det er vigtigt, fordi DORA, NIS2, GDPR, kontrakter, tilsynsforventninger, kunder, cloududbydere og outsourcingaftaler alle bliver krav, der påvirker risikokriterier.

Punkt 5.1 til 5.3 kræver ledelsesforpligtelse, sammenhæng med politikker, ressourcer, ansvar og rapportering af ISMS-resultater til øverste ledelse. Punkt 6.1.1 til 6.1.3 kræver risikobaseret planlægning, en dokumenteret risikovurderingsproces, kriterier for risikoaccept, konsistente vurderingskriterier, risikoejere, sammenligning med risikokriterier, behandlingsplanlægning, en Anvendelseserklæring og godkendelse af restrisiko.

Dette er grundlaget for DORA IKT-risikotolerance.

I risikostyringsfasen instruerer trin 10 i Zenith Blueprint organisationer i at definere risikokriterier, før risici vurderes:

“Risikokriterier er de regler og benchmarks, som din organisation bruger til at evaluere betydningen af hver risiko. Når kriterierne fastlægges på forhånd, sikres det, at alle taler samme risikosprog.”

Det samme trin advarer om, at regulatorisk konsekvens skal indarbejdes i risikodefinitioner:

“Enhver risiko, der kan føre til manglende overholdelse af gældende lovgivning (GDPR osv.), er ikke acceptabel og skal afbødes.”

Zenith Blueprint giver også praktisk vejledning om konsekvensskalering:

“Når konsekvens defineres, er det klogt at relatere niveauer til virksomhedens specifikke skala. For eksempel: ‘Væsentlig finansiel konsekvens = tab > $100k’ (tilpas til jeres kontekst). Overvej også regulatorisk konsekvens: for eksempel kan et brud på persondatasikkerheden automatisk være ‘Væsentligt’ eller ‘Alvorligt’ på grund af GDPR-bøder og underretningskrav, selv om det direkte finansielle tab er uklart. Tilsvarende kan en hændelse, der forårsager driftsafbrydelser, være mindst ‘Væsentlig’ på grund af juridiske konsekvenser, hvis I er omfattet af NIS2 (væsentlige tjenester). Medtag sådanne overvejelser i jeres definitioner.”

Denne vejledning forhindrer en almindelig fejl: at vurdere en cyberrisiko som moderat, fordi det umiddelbare finansielle tab virker lille, mens juridiske konsekvenser, operationel robusthed, konsekvenser for registrerede eller kundepåvirkning ignoreres.

En bestyrelsesklar model bør adskille fire lag:

Denne struktur gør risikovillighed revisionsbar, fordi hver erklæring kan spores til risikokriterier, kontroller, revisionsbevis og beslutninger.

En bestyrelsesklar erklæring om DORA IKT-risikovillighed

En stærk erklæring om IKT-risikovillighed er kort nok til, at bestyrelsen kan godkende den, specifik nok til, at ledelsen kan anvende den, og målbar nok til, at revisorer kan teste den. Den bør undgå jargon, men den må ikke være uklar.

En praktisk overordnet erklæring kunne lyde:

“Vores virksomhed har lav risikovillighed for IKT-risici, der kan medføre væsentlig skade for kunder, afbrydelse af kritiske eller vigtige funktioner, uautoriseret videregivelse eller ændring af regulerede data, manglende opfyldelse af retlige forpligtelser eller tab af robusthed i kritiske IKT-tredjepartstjenester.”

Denne erklæring skal derefter understøttes af målbare tolerancetærskler og eskalationsudløsere.

Denne tabel ændrer samtalen. Bestyrelsen godkender ikke længere et slogan. Den godkender driftsmæssige grænser for tilgængelighed, fortrolighed, integritet, leverandører, sårbarheder, genopretning og efterlevelse.

Clarysecs Politik for risikostyring understøtter denne styringsmodel. Enterprise-politikken angiver:

“Godkender risikostyringsrammen og definerer acceptabel risikovillighed og tolerancetærskler.”

Punkt 6.2.1 gør målingskravet eksplicit:

“Risici skal vurderes for sandsynlighed og konsekvens ved hjælp af en standard risikomatrix med klart definerede scoringsskalaer.”

Punkt 6.3.4 skaber den acceptregel, revisorer forventer:

“Risici, der accepteres uden behandling, skal begrundes skriftligt, knyttes til organisationens risikovillighed og godkendes på det relevante niveau.”

For SMV’er fastholder Politik for risikostyring for SMV’er det samme styringsprincip i et lettere format:

“Sikre ledelsens involvering i godkendelse af risikotolerance og væsentlige risikobehandlingsplaner.”

Den kræver også eskalering af høje risici:

“Høje risici skal eskaleres til direktøren med henblik på beslutning.”

Dette er proportionalitet i praksis. DORA Article 4 kræver, at krav anvendes på en måde, der står i rimeligt forhold til størrelse, risikoprofil samt tjenesternes art, omfang og kompleksitet. ISO/IEC 27001:2022 muliggør samme princip gennem omfang, kontekst, risikokriterier og behandlingsbeslutninger. Styringsstandarden er ikke, at alle organisationer skal have samme komitéstruktur. Styringsstandarden er, at risikovillighed, tolerance, eskalering og accept er defineret, godkendt, dokumenteret og anvendt.

GDPR Article 32 ændrer risikosamtalen

GDPR Article 32 behandles ofte som en teknisk sikkerhedsklausul. Styringsmæssigt er den også en klausul om risikovillighed.

Article 32 kræver, at dataansvarlige og databehandlere implementerer passende tekniske og organisatoriske foranstaltninger for at sikre et sikkerhedsniveau, der passer til risikoen. Den risikobaserede tilgang tager højde for det aktuelle tekniske niveau, implementeringsomkostninger, behandlingens karakter, omfang, kontekst og formål samt risici for fysiske personers rettigheder og frihedsrettigheder.

Dette påvirker IKT-risikovillighed på tre måder.

For det første kan konsekvenser for personoplysninger ikke reduceres til finansielt tab. En eksponering af en lille database kan have begrænset direkte omkostning, men alvorlige konsekvenser for fortrolighed, identitet, svig, diskrimination eller rettigheder. Hvis særlige kategorier af personoplysninger er involveret, såsom helbredsoplysninger, biometriske eller genetiske data, bør risikovilligheden være væsentligt lavere.

For det andet skal behandlingsroller kobles til risikoejerskab. GDPR skelner mellem dataansvarlige og databehandlere. DORA skelner mellem finansielle enheder og IKT-tredjepartsudbydere. NIS2 skelner mellem væsentlige og vigtige enheder. ISO/IEC 27001:2022 kræver risikoejere. En moden erklæring om risikovillighed bør identificere, hvem der ejer risikobeslutninger, der involverer personoplysninger, outsourcet behandling, kritiske tjenester og grænseoverskridende afhængigheder.

For det tredje bør proportionalitet efter Article 32 være synlig i kontroludvælgelsen. Kryptering, pseudonymisering, adgangsstyring, sikkerhedskopiering, logning, overvågning, hændelseshåndtering og robusthed er ikke isolerede tekniske opgaver. De er behandlingsforanstaltninger, der vælges, fordi en risiko oversteg risikovillighed eller tolerance.

Clarysecs Politik for risikostyring kobler dette eksplicit:

“Article 32: Pålægger en risikobaseret tilgang til sikkerhedsforanstaltninger, opfyldt gennem konsekvensbaserede risikoevalueringer og kontroludvælgelse.”

Det er den operationelle forbindelse, revisorer leder efter: krav efter Article 32, risikovurdering, risikoniveau, behandlingsplan, kontroludvælgelse, restrisiko og godkendelse.

Sådan understøtter Zenith Controls revisionsbevis på tværs af krav

En bestyrelsesgodkendt erklæring om risikovillighed bliver stærk, når den kortlægges til kontroller. Zenith Controls fungerer som Clarysecs vejledning til tværgående efterlevelse og hjælper teams med at genbruge revisionsbevis på tværs af ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF og COBIT-lignende assurance.

Tre kontrolområder i ISO/IEC 27002:2022 er særligt vigtige:

Dette er ikke en papirøvelse i kortlægning. Det ændrer, hvordan beslutninger træffes.

Hvis en forretningsejer beder om at acceptere forsinket MFA-udrulning for administratorer, hjælper Zenith Controls CISO’en med at vise, hvorfor dette ikke kun er et spørgsmål om adgangsstyring. Det berører politikstyring, ledelsesansvar, retlige og regulatoriske krav, GDPR’s behandlingssikkerhed, DORA IKT-risikostyring, NIS2-foranstaltninger til cybersikkerhed, hændelseskonsekvens og revisionsbevis.

Hvis et produktteam vil lancere i et nyt EU-marked ved hjælp af en ny cloudtjeneste, flytter ISO/IEC 27002:2022-kontrol 5.31 gennemgangen af retlige og regulatoriske krav ind i ISMS-omfanget. ISO/IEC 27001:2022 punkt 4.2 kræver, at interessentkrav identificeres, herunder retlige, regulatoriske og kontraktlige forpligtelser. Punkt 8.1 kræver operationel planlægning og styring, herunder styring af eksternt leverede processer, produkter eller tjenester, der er relevante for ISMS.

Målet er ét risikosprog, ikke separate efterlevelsesdialekter.

Godkendelsesworkflow: hvem beslutter hvad

En CISO kan foreslå IKT-risikovillighed, men bestyrelsen eller ledelsesorganet skal eje den. Dette ejerskab kræver en arbejdsgang.

Dette er også i overensstemmelse med NIST CSF 2.0. GOVERN-funktionen, især GV.RM, forventer aftalte risikostyringsmål, erklæringer om risikovillighed og tolerance, risikorelaterede aktiviteter integreret i enterprise risk management, definerede risikoresponsmuligheder, kommunikationslinjer og standardiserede metoder til at beregne, dokumentere, kategorisere og prioritere cybersikkerhedsrisici. GV.RR forventer ledelsesansvar, roller, beføjelser og ressourcer tilpasset risikostrategien. GV.PO forventer, at politikker etableres, kommunikeres, håndhæves, gennemgås og opdateres.

COBIT 19- og ISACA-lignende assurance-professionelle vil spørge, om risikovillighed er integreret i virksomhedsstyring af information og teknologi, ikke blot vedhæftet som et bilag til en cyberpolitik.

Opbyg en IKT-risikovillighedspakke på én arbejdssession

En praktisk workshop om IKT-risikovillighed kan flytte en organisation fra spredte registre til et revisionsbart bestyrelsesmateriale.

Trin 1: indsamling af de rigtige input

Forbered det aktuelle IKT-risikoregister, forretningskonsekvensanalyse, genopretningsmål, liste over kritiske eller vigtige funktioner, IKT-aktivfortegnelse, IKT-tjenestefortegnelse, register over leverandør- og cloudafhængigheder, kriterier for hændelsesklassificering, fortegnelse over behandlingsaktiviteter efter GDPR, DPIA’er hvor relevant, register over retlige forpligtelser, politikker, Anvendelseserklæring og eksisterende erklæring om risikovillighed på virksomhedsniveau.

Dette er i overensstemmelse med ISO/IEC 27001:2022 punkt 4, 6 og 8 og med NIST CSF-profilmetoder, der starter med forretningsprioriteter, risikoprioriteter, krav, sikkerhedsforanstaltninger og roller.

Trin 2: definér konsekvensskalaer, der inkluderer regulering

Brug trin 10 i Zenith Blueprint til at definere sandsynlighed og konsekvens i forretningssprog. Medtag finansielt tab, driftsafbrydelse, kundepåvirkning, omdømmeskade, retlig og regulatorisk konsekvens, skade for registrerede og konsekvens for kritiske funktioner.

For eksempel kan “væsentlig” konsekvens omfatte længerevarende afbrydelse af en kritisk tjeneste, bekræftet brud på persondatasikkerheden, der kræver underretning, manglende opfyldelse af en DORA-forpligtelse til hændelsesrapportering eller leverandørsvigt, der påvirker en kritisk eller vigtig funktion.

Trin 3: skriv risikovillighed efter domæne

Opret ikke én generisk cyberrisikovillighed. Definér domæner som tilgængelighed for kritiske tjenester, fortrolighed for personoplysninger, dataintegritet, privilegeret adgang, IKT-tredjepartsafhængighed, cloudkoncentration, sårbarhedseksponering, beredskab til hændelsesrapportering, sikkerhedskopiering og genopretning samt ændringsrisiko ved sikker udvikling.

For hvert domæne skrives én erklæring om risikovillighed, én eller flere tolerancetærskler og eskalationsudløsere.

Trin 4: kobling af behandling til Anvendelseserklæring

Trin 13 i Zenith Blueprint instruerer organisationer i at vælge muligheder for risikobehandling: afbøde, undgå, overføre eller acceptere. Det understreger også ledelsesgodkendelse:

“Risikobehandlingsbeslutninger og SoA bør gennemgås og godkendes af øverste ledelse.”

For DORA og NIS2 er dette revisionsbevis for, at ledelsesorganet eller delegeret ledelse har gennemgået centrale risici, behandlinger og accepteret resteksponering. For GDPR understøtter det ansvarlighed ved at vise, hvorfor de valgte foranstaltninger var passende i forhold til risikoen.

Trin 5: registrér accept med udløb og betingelser

Enhver accepteret mellem eller høj restrisiko bør omfatte:

• Risiko-ID og ejer
• Forretningsmæssig begrundelse
• Reference til erklæring om risikovillighed
• Berørt tolerancetærskel
• Retlig og regulatorisk analyse
• Kompenserende kontroller
• Udløbs- eller gennemgangsdato
• Godkender
• Placering af revisionsbevis
• Udløser for genåbning af beslutningen

Politik for risikostyring for SMV’er angiver:

“Enhver beslutning om at acceptere eller udskyde behandling af en høj eller mellem risiko skal dokumenteres i risikoregisteret. Dokumentationen skal omfatte:”

I enterprise-miljøer bliver dette til et godkendelsesworkflow og risikokomitémateriale. I mindre organisationer kan det være en struktureret fane i risikoregisteret med ledelsens godkendelse. Pointen er ikke bureaukrati. Pointen er juridisk forsvarlighed.

Hændelsestolerance: hvor risikovillighed møder uret

Risikovillighed bliver reel under hændelser.

DORA Article 17 kræver, at finansielle enheder etablerer en proces til styring af IKT-relaterede hændelser for at detektere, håndtere og underrette om hændelser, registrere alle hændelser og væsentlige cybertrusler, identificere rodårsager, anvende tidlige advarselsindikatorer, klassificere hændelser efter prioritet, alvorlighed og tjenestekritikalitet, tildele roller, kommunikere til interessenter, eskalere mindst større IKT-relaterede hændelser til øverste ledelse og ledelsesorganet samt rettidigt gendanne sikker drift.

DORA Article 18 klassificerer hændelser ved hjælp af faktorer som berørte kunder, varighed, nedetid, geografisk udbredelse, datatab, der påvirker tilgængelighed, autenticitet, integritet eller fortrolighed, kritikalitet af berørte tjenester og økonomisk konsekvens. Article 19 kræver, at større IKT-relaterede hændelser rapporteres til den kompetente myndighed, og at kunder informeres, når deres finansielle interesser er påvirket.

NIS2 Article 23 har et trinvist rapporteringsforløb for væsentlige hændelser, herunder tidlig advarsel uden unødig forsinkelse og, hvor relevant, inden for 24 timer, hændelsesunderretning uden unødig forsinkelse og, hvor relevant, inden for 72 timer, mellemliggende opdateringer efter anmodning og en endelig rapport senest én måned efter hændelsesunderretningen. Væsentlige hændelser omfatter hændelser, der forårsager alvorlig driftsafbrydelse, finansielt tab eller væsentlig eller ikke-væsentlig skade for andre.

Erklæringen om risikovillighed bør definere eskalationstærskler, før hændelsen sker.

Bilag A-kontroller om hændelsesplanlægning, vurdering af informationssikkerhedshændelser, hændelseshåndtering, læring fra hændelser, indsamling af bevismateriale, opretholdelse af informationssikkerhed under driftsafbrydelser og IKT-beredskab for forretningskontinuitet understøtter alle disse tærskler. NIST CSF-resultater på tværs af IDENTIFY, PROTECT, DETECT, RESPOND og RECOVER understøtter samme driftsmodel, herunder sikkerhedskopier, overvågning, hændelseserklæring, eskalering, rodårsagsanalyse, interessentkommunikation og verifikation af genopretning.

Leverandør- og cloudtolerance, som bestyrelser ofte overser

DORA gør IKT-tredjepartsrisiko til en central efterlevelsesforpligtelse. Article 28 kræver, at finansielle enheder håndterer IKT-tredjepartsrisiko som en del af IKT-risikostyringsrammen, mens de fortsat har det fulde ansvar for efterlevelse. Den kræver strategi for IKT-tredjepartsrisiko, registre over kontraktlige ordninger for IKT-tjenester, sondring mellem tjenester, der understøtter kritiske eller vigtige funktioner, årlig rapportering, underretning om planlagte ordninger, vurderinger før kontraktindgåelse, due diligence, revisions- og inspektionsrettigheder, ophørsrettigheder og dokumenterede exit-strategier.

Article 29 tilføjer analyse af koncentrationsrisiko, herunder manglende substitutionsmulighed, flere afhængigheder af samme eller forbundne udbydere, underleverandørrisici, underleverandører i tredjelande, overholdelse af databeskyttelseskrav, mulighed for at gøre kontraktvilkår gældende og komplekse underleverandørkæder. Article 30 kræver skriftlige kontraktlige rettigheder og forpligtelser, tjenestebeskrivelser, lokationer, sikkerhedsbeskyttelse, dataadgang og tilbagelevering, serviceniveauer, hændelsesbistand, samarbejde med myndigheder, ophørsrettigheder, testede beredskabsplaner, overvågning og exit-ordninger.

En bestyrelsesgodkendt erklæring om leverandørtolerance kunne lyde:

“Vi har lav risikovillighed for, at kritiske eller vigtige funktioner afhænger af en IKT-tredjepartsudbyder, hvor vi mangler kontraktlige revisionsrettigheder, testede exit-ordninger, pligter til hændelsesunderretning, serviceniveaumål, rettigheder til datatilbagelevering eller indsigt i væsentlig brug af underleverandører.”

Den sætning giver indkøb en praktisk regel. Hvis kontrakten ikke opfylder tærsklen, kan risikoen ikke stiltiende accepteres af projektteamet.

Sådan tester revisorer din IKT-risikovillighed

En stærk erklæring om risikovillighed er designet med revision for øje.

Trin 28 i Zenith Blueprint, i fasen Revision, gennemgang og forbedring, styrker laget for ledelsens gennemgang. Det instruerer organisationer i at indsamle input såsom ændringer i eksterne og interne forhold, ISMS-performance, revisionsresultater, overvågning og måling, hændelser, afvigelser, forbedringsmuligheder og ressourcebehov. Det siger også, at ledelsens gennemgang skal føre til beslutninger og handlinger, ikke blot præsentationer.

Mindst årligt og når der sker væsentlige ændringer, bør ledelsen gennemgå, om tolerancetærskler stadig stemmer overens med forretningsmodellen, om hændelser overskred risikovilligheden, om accepterede risici fortsat ligger inden for godkendte grænser, om nye DORA-, NIS2-, GDPR- eller kontraktlige krav har ændret baseline, om leverandører fortsat ligger inden for koncentrationstolerancer, og om KRI’er medfører rettidig eskalering.

Hvis svaret er nej, skal erklæringen om risikovillighed ændres, eller også skal kontrollerne ændres.

Almindelige svaghedsmønstre i 2026-parathedsarbejde

På tværs af DORA-, NIS2-, GDPR- og ISO/IEC 27001:2022-projekter går de samme svagheder igen:

• Risikovillighed uden tærskler, hvor bestyrelsen godkender en erklæring, men ingen kan sige, hvornår den er overskredet.
• Tærskler uden beføjelser, hvor alvorlighedsniveauer findes, men risikoejere kan acceptere undtagelser uden ledelsesgodkendelse.
• Juridisk risiko uden for scoringsmodellen, hvor GDPR, DORA, NIS2 og kontrakter oplistes separat, men ikke indarbejdes i konsekvenskriterier.
• Leverandørtolerance mangler i bestyrelsesmaterialet, selv om kritiske IKT-afhængigheder er kendt af indkøb eller IT.
• Ledelsens gennemgang som teater, hvor slides præsenteres, men beslutninger, handlinger, ressourcebehov og risikoaccept ikke dokumenteres.
• Fragmenteret revisionsbevis, hvor politikker, registre, KRI’er, hændelsesrapporter, leverandørgennemgange og bestyrelsesreferater findes forskellige steder uden krydshenvisning.

Clarysecs tilgang er designet til at fjerne disse huller. Zenith Blueprint giver den faseopdelte implementeringsvej. Politik for risikostyring og Politik for risikostyring for SMV’er giver styringsklausuler skaleret til enterprise- og SMV-miljøer. Zenith Controls kortlægger kontrolrygraden på tværs af informationssikkerhedspolitik, ledelsesansvar og retlige eller regulatoriske krav, så revisionsbevis kan genbruges på tværs af ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF og COBIT-lignende assurance.

Omsæt bestyrelsens hensigt til revisionsbar IKT-risikostyring

Hvis din organisation har et risikoregister, men ikke kan vise en bestyrelsesgodkendt IKT-risikovillighed, målbare tolerancetærskler, eskalationsudløsere og formelle acceptregler, er manglen ikke kosmetisk. Den påvirker DORA-styring, NIS2-ledelsesansvar, juridisk forsvarlighed efter GDPR Article 32 og ISO/IEC 27001:2022-revisionsberedskab.

Et praktisk næste skridt er at gennemføre en fokuseret workshop om IKT-risikovillighed med Clarysecs værktøjssæt:

1. Brug Zenith Blueprint trin 10 til at definere risikokriterier og konsekvensskalaer.
2. Brug Zenith Blueprint trin 13 til at koble behandlingsmuligheder, restrisiko og godkendelse af Anvendelseserklæring.
3. Brug Zenith Blueprint trin 14 til at krydshenvise GDPR-, NIS2- og DORA-forpligtelser.
4. Brug Zenith Blueprint trin 28 til at bringe risikovillighed, KRI’er, accepterede risici og ressourcebeslutninger ind i ledelsens gennemgang.
5. Anvend Politik for risikostyring eller Politik for risikostyring for SMV’er til at formalisere godkendelses- og acceptregler.
6. Brug Zenith Controls til at kortlægge styringskontroller til revisionsbevis og forventninger til tværgående efterlevelse.

Clarysec kan hjælpe jer med at omsætte spredte risikodokumenter til en bestyrelsesgodkendt, regulatorisk klar model for IKT-risikovillighed, som jeres teams kan bruge, når det næste cloudnedbrud, leverandørsvigt, offentliggørelse af sårbarheder eller hændelse med personoplysninger tester organisationens reelle tolerance.