SLA'er for afhjælpning af sårbarheder i relation til NIS2 og DORA
Kl. 08:17 en tirsdag morgen i begyndelsen af 2026 modtager Anna, CISO i en hurtigt voksende fintech-virksomhed, den første besked, før hun har drukket sin kaffe færdig.
SOC har markeret aktiv diskussion om udnyttelse af en sårbarhed i en kundevendt API-gateway. Udviklings- og driftsteamet siger, at patchen er tilgængelig, men risikabel, fordi gatewayen ligger foran betalingsarbejdsgange. Den complianceansvarlige videresender en formel anmodning fra en national kompetent myndighed, som beder om dokumentation for “håndtering og offentliggørelse af sårbarheder” og dokumentation for, at processen har været effektiv de seneste 12 måneder. Indkøb tilføjer et tredje problem: Gatewayen administreres af en MSP, og kontrakten siger kun, at udbyderen vil anvende “sikkerhedsopdateringer rettidigt”.
Kl. 09:00 er dette ikke længere kun et patchingproblem. Det er et dokumentationsspørgsmål under ISO/IEC 27001:2022, et NIS2-spørgsmål om cyberhygiejne, et DORA-spørgsmål om IKT-risikostyring, et spørgsmål om leverandørstyring og potentielt et spørgsmål om hændelsesrapportering, hvis udnyttelsen påvirker servicekontinuitet eller personoplysninger.
Dette er det praktiske efterlevelsesgab, mange organisationer vil stå over for i 2026. De har scannere, dashboards, tickets og patchværktøjer, men de kan ikke besvare revisionsspørgsmålene klart:
- Hvem godkendte SLA’en for afhjælpning?
- Hvordan er SLA’en risikobaseret?
- Hvad sker der, når en kritisk patch overskrider fristen?
- Hvordan prioriteres internetvendte aktiver?
- Hvordan holdes leverandører på de samme tidsfrister?
- Hvor er registreringen af risikoaccept for et upatchet system?
- Hvilken dokumentation viser, at kontrollen fungerede, og ikke blot eksisterede?
Svaret er ikke endnu et regneark med forfaldsdatoer. SLA’er for afhjælpning af sårbarheder skal styres som et levende kontrolsystem, der forbinder aktivejerskab, sårbarhedsscore, trusselsintelligens, ændringsstyring, leverandør-SLA’er, undtagelseshåndtering, overvågning, hændelseshåndtering og ledelsens gennemgang.
Det er her Clarysecs Enterprise politik for sårbarheds- og patchstyring (VPMP), SMV politik for sårbarheds- og patchstyring (VPMP-SME), SMV-politik for tredjeparts- og leverandørsikkerhed (TPSSP-SME), Zenith Blueprint (ZB) og Zenith Controls (ZC) bliver nyttige. Tilsammen omsætter de “patch hurtigere” til en forsvarlig styringsproces, der kan modstå revisionsmæssig granskning efter ISO, NIS2, DORA, GDPR, NIST og ISACA-praksis.
Hvorfor SLA’er for afhjælpning af sårbarheder blev dokumentation på bestyrelsesniveau
Afhjælpning af sårbarheder blev tidligere behandlet som en IT-hygiejnemetrik. I 2026 ligger det tættere på en reguleret forpligtelse til operationel robusthed.
NIS2 gør cybersikkerhed til et ledelsesansvar. Væsentlige og vigtige enheder skal have ledelsesorganer, der godkender foranstaltninger til cybersikkerhedsrisikostyring, fører tilsyn med implementeringen og modtager træning, så de kan forstå risici og sikkerhedspraksissers betydning for tjenester. NIS2 Article 21 kræver passende og proportionale tekniske, operationelle og organisatoriske foranstaltninger, herunder risikoanalyse, håndtering af hændelser, forretningskontinuitet, sikkerhed i forsyningskæden, sikker anskaffelse og vedligeholdelse, håndtering og offentliggørelse af sårbarheder, cyberhygiejne, træning, adgangsstyring, styring af aktiver og autentifikation.
For finansielle enheder er DORA den specialiserede ordning for operationel robusthed. Den kræver governance- og kontrolordninger for IKT-risiko, hvor ledelsesorganet definerer, godkender, fører tilsyn med og fortsat er ansvarligt for IKT-risikostyringen. Den kræver også identifikation af IKT-aktiver og afhængigheder, beskyttelses- og forebyggelseskontroller såsom patchning og ændringsstyring, styring af IKT-relaterede hændelser, test af digital operationel robusthed og styring af IKT-tredjepartsrisiko.
Den praktiske betydning er væsentlig. En overskredet patchfrist kan indikere svigt i:
- Governance, hvis ledelsen ikke har godkendt risikobaserede SLA’er
- Styring af aktiver, hvis den berørte systemejer er ukendt
- Ændringsstyring, hvis nødpatchning ikke er kontrolleret
- Leverandørstyring, hvis udbyderens tidsfrister er uklare
- Hændelseshåndtering, hvis tegn på udnyttelse ikke triageres
- Styring af dokumentation, hvis tickets og logfiler ikke kan dokumentere lukning
- Risikobehandling, hvis undtagelser ikke godkendes og gennemgås
ISO/IEC 27001:2022 udgør rygraden i ledelsessystemet. Punkt 4.1 til 4.3 kræver, at organisationer forstår interne og eksterne forhold, krav fra interessenter, retlige og kontraktlige forpligtelser samt grænseflader til andre organisationer. Punkt 6.1.1 til 6.1.3 kræver risikovurdering, risikobehandling, en Anvendelseserklæring og risikoejerens godkendelse af restrisiko. Punkt 9.1, 9.2, 9.3, 10.1 og 10.2 kræver overvågning, intern revision, ledelsens gennemgang, løbende forbedring, korrigerende handlinger og opbevaret dokumentation.
Kort sagt: Hvis SLA’er for afhjælpning af sårbarheder skal være revisionsklare, skal de være en del af ISMS — ikke kun en DevOps-metrik.
Den SLA-model, revisorer forventer at se
En SLA for afhjælpning af sårbarheder bør besvare tre spørgsmål:
- Hvor hurtigt skal vi handle?
- Hvem er ansvarlig?
- Hvilken dokumentation viser resultatet?
Politik for sårbarheds- og patchstyring definerer et praktisk udgangspunkt for risikobaserede tidsfrister for afhjælpning:
Organisationen skal klassificere alle detekterede sårbarheder ved hjælp af en standardiseret metode (f.eks. CVSS v3.x) og anvende tidsfrister for afhjælpning, der er tilpasset forretningskritikalitet: 5.2.1 Kritisk (CVSS 9.0-10.0): Øjeblikkelig gennemgang; patchfrist på højst 72 timer. 5.2.2 Høj (7.0-8.9): Respons inden for 48 timer; patchfrist på 7 kalenderdage. 5.2.3 Middel (4.0-6.9): Respons inden for 5 dage; patchfrist på 30 kalenderdage. 5.2.4 Lav (<4.0): Respons inden for 10 dage; patchfrist på 60 kalenderdage.
Denne klausul er stærk, fordi den adskiller responstid fra patchfrist. En høj sårbarhed bør ikke ligge ubemærket i seks dage og derefter patches på dag syv. Responstiden bekræfter triage, ejerskab, konsekvensvurdering og planlægning af afhjælpning. Patchfristen bekræfter teknisk lukning eller en godkendt undtagelse.
For mindre organisationer bruger SMV-politik for sårbarheds- og patchstyring en enklere, men stadig revisionsbar, formulering:
Kritiske patches skal anvendes inden for 3 dage efter frigivelse, særligt for internetvendte systemer
Og for den bredere patchportefølje:
Alle andre patches skal anvendes inden for 30 dage, medmindre en gyldig undtagelse er dokumenteret
Pointen er ikke, at alle organisationer skal bruge identiske frister. ISO/IEC 27001:2022, NIS2 og DORA understøtter alle proportionalitet. Pointen er, at SLA’er for afhjælpning skal være defineret, godkendt, risikobaseret, overvåget og dokumenteret.
| Sårbarhedsklasse | Typisk SLA | Krævet beslutning | Minimumsdokumentation |
|---|---|---|---|
| Kritisk, udnyttet eller internetvendt | 72 timer eller mindre | Nødændring, hændelsestriage, synlighed for CISO | Scannerkonstatering, ticket, ændringsregistrering, patchlog, valideringsscanning |
| Høj på kritisk forretningssystem | 7 kalenderdage | Ejers accept af nedetid eller afbødningsplan | Risikoscore, aktivkritikalitet, ticket, dokumentation for udrulning |
| Middel på internt system | 30 kalenderdage | Standardændring og planlagt udrulning | Patchrapport, lukningsticket, valideringsresultat |
| Lav alvorlighed | 60 kalenderdage eller planlagt cyklus | Backlogejerskab og rutinemæssig overvågning | Ticketstatus, post i risikoregister ved forsinkelse |
| Ikke-patchbart legacy-system | Undtagelsesgennemgang inden for defineret interval | Risikoaccept og kompenserende kontroller | Undtagelsesregistrering, dokumentation for segmentering, overvågningsregel, gennemgangsdato |
Det er her, mange virksomheder fejler. De definerer SLA’en, men ikke dokumentationen. Fra en revisors perspektiv er en politik uden driftsregistreringer et løfte — ikke en kontrol.
Aktivejerskab er den skjulte afhængighed
En scanner kan fortælle dig, at der findes en CVE på en server. Den kan ikke fortælle dig, om serveren understøtter en kritisk betalingsproces, opbevarer særlige kategorier af personoplysninger, forbinder til en afviklingsudbyder eller er planlagt til udfasning.
Den kontekst kommer fra styring af aktiver, dataklassificering, leverandørfortegnelse og risikovurdering.
ISO/IEC 27001:2022 Anneks A-kontrol 8.8, styring af tekniske sårbarheder, er central, men den fungerer ikke alene. Den afhænger i høj grad af konfigurationsstyring, ændringsstyring, leverandørovervågning, cloud governance, logning, overvågning og risikobehandling.
NIST CSF 2.0 udtrykker samme problem i resultatsprog. GOVERN-funktionen forventer, at retlige, regulatoriske og kontraktlige cybersikkerhedskrav forstås og styres, at risikovillighed og tolerance dokumenteres, at roller og ressourcer tildeles, og at cybersikkerhedspolitikker etableres, håndhæves, gennemgås og opdateres. IDENTIFY-resultater omfatter fortegnelser over hardware, software, tjenester, systemer, data og livscyklusser samt sårbarhedsidentifikation, risikoanalyse, undtagelseshåndtering og processer for offentliggørelse af sårbarheder.
I Annas tirsdag morgen-scenarie er det første tekniske spørgsmål: “Hvor er den sårbare komponent?” Det første governance-spørgsmål er: “Hvilken tjeneste og hvilken risiko påvirker den?”
Zenith Blueprint, risikostyringsfasen, Trin 13: Planlægning af risikobehandling og Anvendelseserklæring, håndterer dette ved at forbinde risici med kontroller, ejere og tidsfrister:
Tildel også en ejer og en tidsfrist for hver handling (eventuelt i en separat kolonne eller i kommentarerne). F.eks. “Ejer: IT-chef, tidsfrist: inden Q3 2025.” Det gør det til en egentlig plan.
Det er præcis, hvad afhjælpning af sårbarheder kræver. En konstatering uden en ejer bliver støj i backloggen. En konstatering med en ejer, tidsfrist, risikobehandlingsbeslutning og revisionsspor bliver en revisionsbar kontrol.
Hvordan Zenith Controls kortlægger kontrolrelationerne
Zenith Controls behandler ISO/IEC 27002:2022-kontrol 8.8, styring af tekniske sårbarheder, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Den kobles til cybersikkerhedskoncepterne Identify og Protect, den operationelle kapacitet for trussels- og sårbarhedsstyring samt sikkerhedsdomænerne governance, økosystem, beskyttelse og forsvar.
Det er vigtigt, fordi SLA’er for afhjælpning ikke kun er en beskyttelsesmekanisme. De er også en governance-mekanisme og en økosystemmekanisme. Din eksponering formes af leverandører, cloudplatforme, managed services, open source-komponenter og internetvendte afhængigheder.
Zenith Controls kortlægger 8.8 til flere understøttende kontroller:
| ISO/IEC 27002:2022-kontrolrelation | Hvorfor den er vigtig for SLA’er for afhjælpning |
|---|---|
| 8.7 Beskyttelse mod malware | Malware udnytter ofte kendte, upatchede svagheder, så patchning og antimalwaretelemetri bør forstærke hinanden. |
| 8.9 Konfigurationsstyring | Sikre baselines og konfigurationsregistreringer hjælper med at verificere, om systemer er patchede og fortsat befinder sig i godkendte tilstande. |
| 8.32 Ændringsstyring | Patches er kontrollerede ændringer, herunder nødgodkendelse, test, udrulning, tilbagerulning og gennemgang efter ændringen. |
| 5.22 Overvågning, gennemgang og ændringsstyring af leverandørtjenester | SaaS-, MSP-, PaaS- og cloududbydere skal overvåges for sårbarheder, patches, serviceændringer og hændelser. |
| 5.23 Informationssikkerhed ved brug af cloudtjenester | Brug af cloudtjenester skal omfatte sikkerhedskrav, klarhed om delt ansvar og sikkerhed for patchning, der kontrolleres af udbyderen. |
| 5.24 Planlægning og forberedelse af styring af informationssikkerhedshændelser | Udnyttede sårbarheder kan udvikle sig til hændelser, så triage, eskalering, bevaring af dokumentation og rapportering skal være forberedt. |
Zenith Controls forbinder også sårbarhedsstyring med ISO/IEC 27005:2024, særligt sårbarhedsidentifikation og risikoscenarier, der involverer upatchede systemer. Det styrker argumentet for, at patchfrister bør være risikobaserede og ikke vilkårlige. Det forbinder også leverandørovervågning med ISO/IEC 27036-4:2016 for sikkerhedsniveauer i aftaler om cloudtjenester og ISO/IEC 20000-1:2018 for planlægning af servicelevering og ændringsstyring.
Den struktur på tværs af standarder har betydning under revision. Hvis en organisation siger, at “kritiske sårbarheder patches inden for 72 timer”, vil revisor teste, om udsagnet understøttes af risikovurdering, aktivklassificering, leverandørforpligtelser, ændringsregistreringer og overvågningsdokumentation.
NIS2-cyberhygiejne: fra håndtering af sårbarheder til korrigerende handling
NIS2 Article 21 kræver en all-hazards-tilgang til net- og informationssystemer. For SLA’er for afhjælpning af sårbarheder er flere elementer i Article 21 direkte relevante:
- Risikoanalyse og informationssystemsikkerhedspolitikker
- Håndtering af hændelser
- Forretningskontinuitet og krisestyring
- Sikkerhed i forsyningskæden
- Sikker anskaffelse, udvikling og vedligeholdelse, herunder håndtering og offentliggørelse af sårbarheder
- Procedurer til at vurdere cybersikkerhedseffektivitet
- Grundlæggende cyberhygiejne og træning
- Adgangsstyring og styring af aktiver
- Multi-factor authentication eller løbende autentifikation, hvor det er relevant
NIS2 Article 20 gør ledelsesorganer ansvarlige for at godkende og føre tilsyn med foranstaltninger til cybersikkerhedsrisikostyring. Det betyder, at metrikker for afhjælpning af sårbarheder ikke kun kan leve i et engineering-dashboard. De bør indgå i ledelsesrapportering, materiale til risikokomitéen eller registreringer fra ISMS-ledelsens gennemgang.
Article 21 forventer også, at enheder, der identificerer manglende overholdelse af krævede foranstaltninger, træffer korrigerende handlinger uden unødig forsinkelse. Den formulering er vigtig. Hvis dit dashboard viser forfaldne kritiske sårbarheder, bør dokumentationen for efterlevelse ikke stoppe ved “vi ved det”. Den bør vise eskalering, risikogennemgang, synlighed for ledelsen, korrigerende handlinger og revurdering.
NIS2 Article 23 tilføjer endnu en dimension. Hvis udnyttelse af en upatchet sårbarhed forårsager eller kan forårsage alvorlig driftsforstyrrelse, økonomisk tab eller skade på andre personer, kan det blive en væsentlig hændelse. Rapporteringslivscyklussen omfatter tidlig varsling inden for 24 timer efter at være blevet bekendt med den væsentlige hændelse, hændelsesunderretning inden for 72 timer, mellemliggende rapporter efter anmodning og en endelig rapport senest én måned efter hændelsesunderretningen. Den endelige rapport bør indeholde alvorlighed, påvirkning, sandsynlig rodårsag, afbødninger og eventuel grænseoverskridende påvirkning.
SLA-processen skal derfor forbindes med hændelseshåndtering. En kritisk sårbarhed med dokumentation for aktiv udnyttelse bør udløse sikkerhedstriage, overvågning, bevaring af dokumentation og en vurdering af rapporteringspligt — ikke kun en rutinemæssig patchticket.
DORA IKT-risiko: tidsfrister for afhjælpning som dokumentation for robusthed
For finansielle enheder gælder DORA fra 17. januar 2025 og skaber ensartede krav på tværs af IKT-risikostyring, rapportering af større IKT-relaterede hændelser, test af digital operationel robusthed, informationsdeling og styring af IKT-tredjepartsrisiko. Den behandles som den sektorspecifikke EU-retsakt for omfattede finansielle enheder identificeret efter nationale NIS2-regler.
DORAs driftsmodel ligger tæt på et integreret ISMS. Article 5 og Article 6 kræver governance, politikker, procedurer, værktøjer, årlig eller periodisk gennemgang, revision, afhjælpning af kritiske revisionskonstateringer og en strategi for digital operationel robusthed. Article 8 kræver identifikation og registrering af IKT-understøttede forretningsfunktioner, informationsaktiver, IKT-aktiver, afhængigheder, tredjepartsprocesser og legacy-IKT-risici. Article 9 kræver beskyttelses- og forebyggelseskontroller, herunder patchning og ændringsstyring. Article 11 og Article 12 kræver kontinuitet, respons, genopretning, backup, gendannelse og genopretningsmål.
DORA Article 17 til Article 19 kræver en proces for styring af IKT-relaterede hændelser, som detekterer, håndterer, registrerer, klassificerer, eskalerer, rapporterer, kommunikerer, analyserer rodårsag og genetablerer sikker drift. Article 24 til Article 26 kræver test af digital operationel robusthed, herunder passende test af IKT-værktøjer og -systemer, sårbarhedsvurderinger, netværkssikkerhedsvurderinger, gap-analyser, kildekodegennemgange hvor det er muligt, penetrationstest og trusselsbaseret penetrationstest for visse finansielle enheder. Article 28 og Article 30 kræver styring af IKT-tredjepartsrisiko, registre over IKT-tjenestekontrakter, due diligence, revisions- og inspektionsrettigheder, serviceniveauer, leverandørbistand under hændelser, opsigelsesrettigheder og exitordninger.
For SLA’er for afhjælpning ændrer DORA dokumentationsforventningerne på tre måder.
For det første skal sårbarhedskonstateringer fra test indgå i en prioriteret afhjælpningsproces. En scanningsrapport er ikke nok.
For det andet skal afhjælpning af kritiske konstateringer spores gennem governance og revision. DORA forventer formel afhjælpning af kritiske revisionskonstateringer for ikke-mikrovirksomheder.
For det tredje skal IKT-tredjepartsudbydere holdes ansvarlige for målbare forpligtelser. Hvis din cloud-, SaaS- eller MSP-udbyder kontrollerer patchvinduet, skal din kontrakt og dit register vise, hvordan deres tidsfrister for afhjælpning understøtter dine robusthedsforpligtelser.
Politik for sårbarheds- og patchstyring adresserer dette direkte:
Patchning hos tredjeparter og tilsyn med SaaS-risiko 6.6.1 Alle tredjepartssystemer (SaaS, PaaS, MSP-administrerede) skal kunne dokumentere tilstrækkelige kontroller for sårbarheds- og patchstyring. 6.6.2 Leverandør-SLA’er skal omfatte tidsfrister for afhjælpning, der svarer til internt definerede tærskler baseret på kritikalitet.
Den klausul er ofte den manglende bro mellem intern ISO-dokumentation og DORA-leverandørtilsyn.
GDPR: når patchforsinkelser bliver svigt i ansvarlighed for personoplysninger
GDPR er ikke en standard for sårbarhedsstyring, men den ændrer konsekvenserne af patchsvigt.
GDPR Article 5 kræver, at personoplysninger behandles sikkert, og kræver, at den dataansvarlige kan dokumentere overholdelse. Article 32 kræver passende tekniske og organisatoriske foranstaltninger for at sikre et sikkerhedsniveau, der passer til risikoen. Når upatchede systemer behandler personoplysninger, særligt identitetsdata, finansielle data, biometriske data, helbredsdata, ansættelsesdata eller KYC-oplysninger, bliver SLA’er for afhjælpning en del af ansvarligheden for behandlingssikkerhed.
En forsinket patch kan være forsvarlig, hvis risikoen blev vurderet, kompenserende kontroller blev anvendt, og restrisiko blev accepteret af den rette person. Det er langt sværere at forsvare, hvis sårbarheden var forfalden, internetvendt og uden ejer.
Zenith Controls kortlægger sårbarhedsstyring til GDPR Article 32 og Article 5(1)(f), fordi rettidig patchning reducerer risici for fortrolighed og integritet af personoplysninger. Den kortlægger også ændringsstyring til GDPR Article 24 og Article 32, fordi ændringer i systemer, der behandler personoplysninger, bør risikovurderes, godkendes, dokumenteres og gennemgås.
Læren for efterlevelse er enkel: Hvis personoplysninger er involveret, bør din patchdokumentation omfatte datakonteksten. Revisorer og tilsynsmyndigheder vil ikke kun spørge “blev det patchet?”, men “hvilke data var udsat for risiko, hvor længe, og hvilke kontroller reducerede den risiko?”
En praktisk Clarysec-arbejdsgang for revisionsklar SLA-dokumentation
En moden proces for afhjælpning af sårbarheder begynder ikke, når en revisor beder om registreringer. Den er designet til at producere registreringer hver måned.
Trin 1: Godkend SLA-politikken
Start med Politik for sårbarheds- og patchstyring eller SMV-politik for sårbarheds- og patchstyring, afhængigt af din driftsmodel. Tilpas SLA-tærskler til risikovillighed, regulatorisk omfang, tjenestekritikalitet, datafølsomhed og tekniske begrænsninger. Sørg for godkendelse fra CISO, risikokomité eller ledelsesorgan.
For enterprise-miljøer skal CVSS, aktivkritikalitet, udnyttelighed, interneteksponering, datafølsomhed og forretningsmæssig konsekvens anvendes. For SMV’er skal modellen holdes enkel, men eksplicit: kritiske patches inden for tre dage, andre patches inden for 30 dage, medmindre der findes en gyldig undtagelse.
Trin 2: Kortlæg aktiver til ejere og kritiske tjenester
Hver sårbarhedskonstatering bør kunne henføres til:
- Aktivnavn og unik identifikator
- Forretningstjeneste eller applikation
- Systemejer
- Teknisk ejer
- Dataklassificering
- Interneteksponering
- Leverandørafhængighed, hvis relevant
- Kritikalitet for den understøttede funktion
Dette understøtter ISO/IEC 27001:2022-risikoejerskab, NIS2-styring af aktiver, DORA-fortegnelse over IKT-aktiver og afhængigheder samt NIST CSF IDENTIFY-resultater.
Trin 3: Triagér sårbarheden
Opret en ticket for hver konstatering eller grupperet sæt af konstateringer. Medtag CVSS-score, kildescanner, berørt aktiv, exploitstatus, trusselsintelligens, forretningskritikalitet og påkrævet SLA. Hvis der er mistanke om udnyttelse, skal ticketen knyttes til en hændelsesvurdering.
Trin 4: Gennemfør via ændringsstyring
Patchning er en ændring. Brug standardændring til rutineopdateringer og nødændring til kritiske, udnyttede sårbarheder. Medtag testdokumentation, godkendelse, implementeringstidspunkt, tilbagerulningsplan og validering efter ændringen.
Dette matcher Zenith Controls-relationen mellem 8.8 og 8.32, hvor anvendelse af patches styres gennem ændringsstyring for at balancere hast og driftsstabilitet.
Trin 5: Validér lukning
Luk ikke tickets alene på grundlag af “patch installeret”. Kræv validering gennem rescanning, versionsbekræftelse, konfigurationsverifikation eller bekræftelse af kompenserende kontrol. Hvor patchen ikke kan anvendes, skal der oprettes en undtagelse.
Trin 6: Registrér undtagelser og restrisiko
Politik for sårbarheds- og patchstyring definerer det krævede indhold i undtagelser:
Undtagelsesanmodninger skal indeholde: 7.2.1 Forretningsmæssig begrundelse for forsinkelsen eller den manglende afhjælpning 7.2.2 Risikovurdering (baseret på CVSS, aktivkritikalitet, trusselsintelligens) 7.2.3 Foreslåede kompenserende kontroller 7.2.4 Tidsfrist for afhjælpning eller revurdering
Den definerer også godkendelse og gennemgang:
Undtagelser skal godkendes af CISO eller en delegeret risikokomité og registreres i ISMS-undtagelsesregisteret med et gennemgangsinterval på højst 90 dage.
Det undtagelsesregister bliver væsentligt revisionsbevis for ISO/IEC 27001:2022 punkt 6.1.3 risikobehandling og accept af restrisiko samt for ledelsens gennemgang.
| Undtagelsesfelt | Eksempeldokumentation |
|---|---|
| Aktiv-ID | PROD-DB-04, Legacy Customer Analytics DB |
| Sårbarhed | Kritisk sårbarhed for fjernudførelse af kode med CVSS 9.8 |
| Forretningsmæssig begrundelse | Patchen er inkompatibel med et legacy-runtime-miljø og vil forårsage nedetid for en applikation, der er planlagt til udfasning |
| Risikovurdering | Ikke internetvendt, høj forretningsmæssig konsekvens, ingen aktiv exploit mod denne konfiguration, risikoen er fortsat høj, men reduceret |
| Kompenserende kontroller | Sikker VLAN, stramme firewallregler, udvidet logning, integritetskontroller, bastionadgang med MFA |
| Tidsfrist for afhjælpning | Udfasning senest 31. oktober 2026, undtagelse gennemgås hver 90. dag |
| Godkendelse | CISO-godkendelse, post i ISMS-undtagelsesregister, risikoejers accept |
Denne registrering dokumenterer, at organisationen ikke ignorerede sårbarheden. Den vurderede risikoen, anvendte kompenserende kontroller, godkendte restrisiko og fastsatte en gennemgangsdato.
Trin 7: Opbyg den månedlige dokumentationspakke
Din månedlige dokumentationspakke for afhjælpning af sårbarheder bør omfatte:
| Dokumentationselement | Formål | Revisionsværdi |
|---|---|---|
| Godkendt sårbarheds- og patchpolitik | Definerer kriterier og SLA’er | Viser governance og ledelsesgodkendelse |
| Eksport af aktivkritikalitet | Kobler sårbarheder til forretningsmæssig konsekvens | Understøtter risikobaseret prioritering |
| Scannerrapport | Viser detektionsdækning | Dokumenterer, at sårbarheder identificeres |
| Ticketeksport | Viser tildeling, datoer og status | Dokumenterer arbejdsgang og ansvarlighed |
| Ændringsregistreringer | Viser kontrolleret udrulning | Dokumenterer, at patches blev godkendt og implementeret |
| Valideringsscanning | Bekræfter afhjælpning | Dokumenterer effektivitet |
| Undtagelsesregister | Viser accepteret restrisiko | Dokumenterer, at forsinkelser styres |
| Leverandør-SLA-tracker | Viser tredjepartsforpligtelser | Dokumenterer tilsyn med forsyningskæden |
| KPI-dashboard | Viser performanceudvikling | Understøtter ledelsens gennemgang |
| Log over korrigerende handlinger | Viser forbedringer ved svigt | Understøtter håndtering af afvigelser |
For SMV’er kan dokumentationen være lettere, men den skal stadig være konsistent. SMV-politik for sårbarheds- og patchstyring kræver patchlogfiler med sporbarhed:
Logfiler skal indeholde enhedsnavn, anvendt opdatering, patchdato og årsag til eventuel forsinkelse
Den ene klausul er revisionsguld. Den gør patchning fra en påstand til en registrering.
Leverandørpatchning: kontrakten skal matche din SLA
Hvis en MSP, SaaS-udbyder, PaaS-udbyder eller udbyder af cloudtjenester kontrollerer patchudrulningen, er interne SLA’er uden værdi, medmindre leverandørforpligtelserne matcher dem.
SMV-politik for tredjeparts- og leverandørsikkerhed omfatter informationssikkerhedsforpligtelser som et styringskrav. For afhjælpning af sårbarheder bør disse forpligtelser omsættes til målbare kontraktvilkår:
- Underretningsvinduer for kritiske sårbarheder
- Tidsfrister for afhjælpning af kritiske, høje, middel og lave sårbarheder
- Proces for nødændringer
- Kundekrav til godkendelse af nedetid
- Dokumentationsformat for fuldført patchning
- Proces for offentliggørelse af sårbarheder
- Forpligtelser til bistand ved hændelser
- Ret til revision eller modtagelse af assurance-rapporter
- Patchforpligtelser for underdatabehandlere eller underleverandører
- Exit- og overgangsstøtte for kritiske tjenester
Zenith Blueprint, fasen Kontroller i praksis, Trin 20, Control 8.21 Security of network services, angiver princippet klart:
Hvor tjenester leveres eksternt, herunder ISP’er, SD-WAN-leverandører eller private cloududbydere, skal sikkerhedskrav indarbejdes i kontrakter og SLA’er. Dette omfatter oppetidsgarantier, responstider for hændelser, forpligtelser til patchning eller afbødning af sårbarheder og klare grænser for datahåndtering. Du bør aldrig antage, at en udbyder lever op til dine forventninger, medmindre det er skriftligt, målbart og revisionsbart.
DORA gør dette særligt vigtigt for finansielle enheder. IKT-tredjepartsaftaler skal omfatte serviceniveauer, leverandørbistand under IKT-hændelser, adgang til og gendannelse af data, samarbejde med myndigheder, opsigelsesrettigheder og stærkere bestemmelser for kritiske eller vigtige funktioner, herunder overvågning, revisionsrettigheder, beredskabsplaner og sikkerhedsforanstaltninger.
NIST CSF 2.0 siger det samme gennem resultater for forsyningskæderisiko: Leverandører bør være kendte, prioriteret efter kritikalitet, vurderet før engagement, styret af kontraktlige krav, overvåget gennem hele relationen, inkluderet i hændelsesplanlægning og håndteret ved ophør.
Hvad revisorer faktisk vil spørge om
Revisionsdialogen ændrer sig afhængigt af revisors baggrund.
En ISO/IEC 27001:2022-revisor vil starte med ISMS. Revisoren vil kontrollere, om sårbarhedsstyring er inkluderet i Anvendelseserklæringen, om risikovurderingen identificerer upatchede systemer som en risiko, om risikobehandlingsplaner har ejere og tidsfrister, om Anneks A-kontrol 8.8 er implementeret, om dokumentation opbevares, og om intern revision og ledelsens gennemgang evaluerer performance.
Zenith Blueprint, fasen Kontroller i praksis, Trin 19, gør revisionsforventningen eksplicit:
Dette er en højt prioriteret kontrol for revisorer, og de vil normalt gå i dybden. Forvent at blive spurgt, hvor ofte systemer patches, hvilken proces I følger, når en zero-day annonceres, og hvilke systemer der er sværest at patche.
Den fortsætter med praktiske dokumentationsforventninger:
Revisorer vil sandsynligvis anmode om resultater fra sårbarhedsscanninger. Hvis I bruger værktøjer som Nessus, OpenVAS eller Qualys, skal I eksportere en rapport, der viser nyligt detekterede sårbarheder, og hvordan de blev håndteret. Ideelt set bør den omfatte risikovurderinger (CVSS) og tidsfrister for afhjælpning.
En NIS2-fokuseret revisor eller kompetent myndighed vil se efter bestyrelsesgodkendelse, proportionalitet, cyberhygiejne, håndtering af sårbarheder, leverandørsikkerhed, håndtering af hændelser, effektivitetsvurdering, korrigerende handlinger uden unødig forsinkelse og registreringer af rapporteringsbeslutninger, hvis udnyttelse forårsagede væsentlig påvirkning.
En DORA-tilsynsmyndighed vil teste, om sårbarhedskonstateringer er integreret i IKT-risikostyring, test af digital operationel robusthed, hændelsesklassificering, rodårsagsanalyse, tredjepartsregistre, kontraktlige forpligtelser, revisionsrettigheder og afhjælpning af kritiske konstateringer.
En NIST CSF-vurderingspart vil sandsynligvis strukturere gennemgangen omkring GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND og RECOVER. De vil spørge, om retlige og kontraktlige krav forstås, om risikotolerance er dokumenteret, om sårbarheder identificeres og prioriteres, om undtagelser håndteres, om overvågning detekterer udnyttelse, og om respons- og genopretningshandlinger koordineres.
En COBIT 2019- eller ISACA-orienteret revisor vil fokusere på styringsmål, proceskapabilitet, ledelsespraksis, metrikker, ejerskab, kontroldesign, kontroludførelse og dokumentationens tilstrækkelighed. De vil spørge, om afhjælpning af sårbarheder er gentagelig, målt, eskaleret, forbedret og tilpasset virksomhedens mål og risikovillighed.
| Revisionsperspektiv | Sandsynligt spørgsmål | Stærk dokumentation |
|---|---|---|
| ISO/IEC 27001:2022 | Er sårbarhedsstyring risikobaseret og inkluderet i ISMS? | SoA, risikoregister, politik, behandlingsplan, revisionsoptegnelser |
| NIS2 | Er cyberhygiejne og håndtering af sårbarheder godkendt, overvåget og korrigeret uden unødig forsinkelse? | Ledelsesreferater, SLA-dashboard, korrigerende handlinger, vurdering af hændelsesrapportering |
| DORA | Styres IKT-sårbarheder som en del af robusthed og tredjepartsrisiko? | IKT-aktivfortegnelse, testresultater, afhjælpningsplan, leverandørregister, kontrakt-SLA’er |
| GDPR | Kan patchforsinkelse påvirke sikkerheden for personoplysninger? | Dataklassificering, risikovurdering, vurdering af brud, kompenserende kontroller |
| NIST CSF 2.0 | Er aktuelle og ønskede resultater defineret, og er mangler prioriteret? | CSF-profil, POA&M, sårbarhedsmetrikker, undtagelsesregistreringer |
| COBIT 2019 eller ISACA | Er processen styret, målt og effektiv? | RACI, KPI- og KRI-tendenser, kontroltest, ledelsesrapportering |
Eskalering og metrikker: hvordan du dokumenterer, at SLA’en styres
En SLA uden eskalering er kun et mål. Et forsvarligt program for afhjælpning af sårbarheder kræver eskalering før brud, ved brud og efter gentagne svigt.
Clarysec anbefaler en eskaleringsmodel i fire niveauer:
- Driftsmæssig eskalering, ticketejer og teknisk ansvarlig underrettes før brud.
- Risikoeskalering, aktivejer og risikoejer gennemgår konsekvensen, når brud er sandsynligt.
- Sikkerhedsstyringseskalering, CISO eller risikokomité godkender undtagelse eller nødhandling.
- Ledelseseskalering, gentagne eller kritiske SLA-brud rapporteres til ledelsens gennemgang med korrigerende handlinger.
Politik for sårbarheds- og patchstyring styrker denne revisionsforventning:
Periodiske revisioner skal udføres af intern revision eller en uafhængig tredjepart for at verificere: 5.6.1 Overholdelse af SLA’er 5.6.2 Dokumentation for risikobaseret prioritering 5.6.3 Effektivitet af implementerede patches 5.6.4 Kontroller over upatchede systemer
Metrikker bør understøtte beslutninger — ikke pynte dashboards. De stærkeste metrikker i 2026 omfatter:
- Procentvis overholdelse af SLA for kritiske sårbarheder
- Procentvis overholdelse af SLA for høje sårbarheder
- Gennemsnitlig tid til triage
- Gennemsnitlig tid til afhjælpning pr. aktivklasse
- Antal forfaldne kritiske sårbarheder
- Antal accepterede undtagelser efter alder
- Undtagelser over 90 dage
- Antal kritiske internetvendte eksponeringer
- Leverandør-SLA-brud
- Sårbarheder genåbnet efter validering
- Nødændringer forårsaget af udnyttede sårbarheder
- Patchsvigt pr. platform eller forretningsenhed
Knyt disse metrikker til ISO/IEC 27001:2022 punkt 9.3 ledelsens gennemgang, DORA-governancerapportering og NIS2-ledelsestilsyn. For NIST CSF 2.0 skal de bruges til at opdatere aktuelle profiler og målprofiler, gap-analyse og handlingsplaner.
Clarysecs tjekliste for afhjælpnings-SLA’er
Brug denne tjekliste til at evaluere dit nuværende program:
- Findes der en godkendt politik for sårbarheds- og patchstyring?
- Er SLA’er for afhjælpning defineret efter alvorlighed og forretningskritikalitet?
- Fremskyndes internetvendte og udnyttede sårbarheder?
- Er aktiver kortlagt til ejere, tjenester, data og leverandører?
- Konverteres scannerkonstateringer til tildelte tickets?
- Gennemføres patches via ændringsstyring?
- Dokumenteres og gennemgås nødændringer?
- Valideres afhjælpningsresultater med rescanninger eller versionskontroller?
- Risikovurderes, godkendes og gennemgås undtagelser mindst hver 90. dag?
- Dokumenteres kompenserende kontroller for systemer, der ikke kan patches?
- Er leverandørkontrakter tilpasset interne tærskler for afhjælpning?
- Er patchlogfiler tilstrækkeligt fuldstændige til at dokumentere, hvad der skete og hvornår?
- Eskaleres og korrigeres SLA-brud?
- Gennemgås metrikker af ledelsen?
- Udløses hændelses- og brudvurderinger, når der er mistanke om udnyttelse?
Hvis flere svar er “nej”, er problemet ikke værktøjerne. Det er kontroldesignet.
Næste skridt: gør patchfrister til revisionsklar robusthed
SLA’er for afhjælpning af sårbarheder i 2026 skal gøre mere end at tilfredsstille et scanner-dashboard. De skal dokumentere, at organisationen kan identificere eksponering, prioritere risiko, handle inden for godkendte tidsfrister, styre undtagelser, håndtere leverandører og dokumentere beslutninger på tværs af revisionsforventninger i ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 2019.
Clarysec kan hjælpe dig med at gå fra fragmenterede patchtickets til et integreret, dokumentationsdrevet program for afhjælpning af sårbarheder ved hjælp af:
- Politik for sårbarheds- og patchstyring
- SMV-politik for sårbarheds- og patchstyring
- SMV-politik for tredjeparts- og leverandørsikkerhed
- Zenith Blueprint: En revisors 30-trins køreplan
- Zenith Controls: Guiden til tværgående efterlevelse
Start med én højrisikotjeneste. Kortlæg dens aktiver, leverandører, sårbarheder, tickets, ændringer, undtagelser og dokumentation. Kør derefter revisionsspørgsmålene mod den. Hvis du ikke kan dokumentere SLA’en fra detektion til lukning, er det dit første afhjælpningsprojekt.
Målet er ikke perfekt patchning. Målet er styret, risikobaseret, målbar og revisionsbar afhjælpning. Download Clarysecs politikskabeloner, gennemfør en målrettet gap-analyse, eller book en Clarysec-demo for at gøre afhjælpning af sårbarheder fra revisionspres til operationel robusthed.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
