SLA för åtgärdande av sårbarheter enligt NIS2 och DORA

Klockan 08:17 en tisdagsmorgon i början av 2026 får Anna, CISO i ett snabbväxande fintechbolag, dagens första meddelande innan kaffet är urdrucket.

SOC har flaggat för aktiv exploateringsdiskussion kring en sårbarhet i en kundvänd API-gateway. Engineering säger att patchen finns tillgänglig men är riskfylld, eftersom gatewayen ligger framför betalningsflöden. Complianceansvarig vidarebefordrar en formell begäran från en nationell behörig myndighet som efterfrågar underlag för “hantering och rapportering av sårbarheter” samt bevis för att processen har varit effektiv under de senaste 12 månaderna. Upphandling lägger till ett tredje problem: gatewayen hanteras av en MSP, och avtalet säger endast att leverantören ska tillämpa “säkerhetsuppdateringar inom skälig tid”.

Klockan 09:00 är detta inte längre enbart en patchningsfråga. Det är en fråga om underlag enligt ISO/IEC 27001:2022, en fråga om cyberhygien enligt NIS2, en fråga om IKT-riskhantering enligt DORA, en fråga om leverantörsstyrning och potentiellt en fråga om incidentrapportering om exploateringen påverkar tjänstekontinuitet eller personuppgifter.

Detta är den praktiska efterlevnadslucka som många organisationer kommer att möta under 2026. De har skannrar, kontrollpaneler, ärenden och patchverktyg, men de kan inte tydligt besvara revisionsfrågorna:

• Vem godkände SLA:t för åtgärdande?
• Hur är SLA:t riskbaserat?
• Vad händer när en kritisk patch missar tidsfristen?
• Hur prioriteras internetexponerade tillgångar?
• Hur hålls leverantörer till samma tidsramar?
• Var finns riskacceptansposten för ett opatchat system?
• Vilket underlag visar att kontrollen fungerade, inte bara att den fanns?

Svaret är inte ytterligare ett kalkylblad med förfallodatum. SLA för åtgärdande av sårbarheter ska hanteras som ett levande kontrollsystem som kopplar samman tillgångsägarskap, sårbarhetspoängsättning, hotinformation, ändringshantering, leverantörs-SLA, undantagshantering, övervakning, incidenthantering och ledningens genomgång.

Det är här Clarysecs Enterprise Policy för sårbarhets- och patchhantering (VPMP), SME Policy för sårbarhets- och patchhantering – SME (VPMP-SME), Policy för leverantörssäkerhet och tredjepartssäkerhet – SME (TPSSP-SME), Zenith Blueprint (ZB) och Zenith Controls (ZC) blir användbara. Tillsammans omvandlar de “patcha snabbare” till en försvarbar styrningsprocess som klarar revisionsgranskning enligt ISO, NIS2, DORA, GDPR, NIST och ISACA-liknande förväntningar.

Varför SLA för åtgärdande av sårbarheter har blivit underlag på styrelsenivå

Åtgärdande av sårbarheter behandlades tidigare som ett IT-hygienmått. Under 2026 ligger det närmare ett reglerat åtagande om operativ resiliens.

NIS2 gör cybersäkerhet till en fråga om ledningens ansvarsskyldighet. Väsentliga och viktiga enheter ska låta ledningsorgan godkänna åtgärder för cybersäkerhetsriskhantering, övervaka genomförandet och få utbildning så att de förstår risker och hur säkerhetspraxis påverkar tjänster. NIS2 Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning och underhåll, hantering och rapportering av sårbarheter, cyberhygien, utbildning, åtkomstkontroll, tillgångshantering och autentisering.

För finansiella enheter är DORA det specialiserade regelverket för operativ resiliens. Det kräver styrnings- och kontrollarrangemang för IKT-risk där ledningsorganet definierar, godkänner och övervakar IKT-riskhanteringen och fortsatt ansvarar för den. Det kräver också identifiering av IKT-tillgångar och beroenden, skyddande och förebyggande kontroller såsom patchning och ändringshantering, hantering av IKT-relaterade incidenter, testning av digital operativ resiliens och hantering av IKT-tredjepartsrisk.

Den praktiska effekten är betydande. En missad patchningsfrist kan indikera brister i:

• Styrning, om ledningen inte har godkänt riskbaserade SLA
• Tillgångshantering, om berörd systemägare är okänd
• Ändringshantering, om akut patchning inte styrs
• Leverantörsstyrning, om leverantörens tidsramar är otydliga
• Incidenthantering, om tecken på exploatering inte triageras
• Underlagshantering, om ärenden och loggar inte kan bevisa stängning
• Riskbehandling, om undantag inte godkänns och granskas

ISO/IEC 27001:2022 ger ledningssystemets stomme. Klausulerna 4.1 till 4.3 kräver att organisationer förstår interna och externa frågor, intressentkrav, rättsliga och avtalsmässiga skyldigheter samt gränssnitt mot andra organisationer. Klausulerna 6.1.1 till 6.1.3 kräver riskbedömning, riskbehandling, en tillämpbarhetsförklaring och riskägarens godkännande av kvarstående risk. Klausulerna 9.1, 9.2, 9.3, 10.1 och 10.2 kräver övervakning, internrevision, ledningens genomgång, ständig förbättring, korrigerande åtgärder och bevarad dokumenterad information.

Enkelt uttryckt: om SLA för åtgärdande av sårbarheter ska vara revisionsklara måste de ingå i ISMS, inte bara vara ett DevOps-mått.

SLA-modellen som revisorer förväntar sig att se

Ett SLA för åtgärdande av sårbarheter ska besvara tre frågor:

1. Hur snabbt måste vi agera?
2. Vem är ansvarig?
3. Vilket underlag visar resultatet?

Policy för sårbarhets- och patchhantering definierar en praktisk utgångspunkt för riskbaserade tidsramar för åtgärdande:

Organisationen ska klassificera alla upptäckta sårbarheter med en standardiserad metodik (t.ex. CVSS v3.x) och tillämpa tidsramar för åtgärdande som är anpassade till verksamhetskritikalitet: 5.2.1 Kritisk (CVSS 9.0-10.0): Omedelbar granskning; patchningsfrist på högst 72 timmar. 5.2.2 Hög (7.0-8.9): Respons inom 48 timmar; patchningsfrist på 7 kalenderdagar. 5.2.3 Medel (4.0-6.9): Respons inom 5 dagar; patchningsfrist på 30 kalenderdagar. 5.2.4 Låg (<4.0): Respons inom 10 dagar; patchningsfrist på 60 kalenderdagar.

Denna klausul är kraftfull eftersom den skiljer responstid från patchningsfrist. En hög sårbarhet ska inte ligga oupptäckt i sex dagar och sedan patchas dag sju. Responsklockan bekräftar triage, ägarskap, konsekvensbedömning och planering av åtgärdande. Patchningsfristen bekräftar teknisk stängning eller ett godkänt undantag.

För mindre organisationer använder Policy för sårbarhets- och patchhantering – SME enklare men fortfarande revisionsbar formulering:

Kritiska patchar ska installeras inom 3 dagar från utgivning, särskilt för internetexponerade system

Och för den bredare patchmiljön:

Alla övriga patchar ska installeras inom 30 dagar, om inte ett giltigt undantag dokumenteras

Poängen är inte att varje organisation måste använda identiska tidsfrister. ISO/IEC 27001:2022, NIS2 och DORA stödjer alla proportionalitet. Poängen är att SLA för åtgärdande ska vara definierade, godkända, riskbaserade, övervakade och styrkta med underlag.

Det är här många företag brister. De definierar SLA:t men inte underlaget. Ur revisorns perspektiv är en policy utan operativa poster ett löfte, inte en kontroll.

Tillgångsägarskap är det dolda beroendet

En skanner kan visa att en CVE finns på en server. Den kan inte säga om servern stödjer en kritisk betalningsprocess, lagrar känsliga personuppgifter, ansluter till en avvecklingsleverantör eller är planerad för avveckling.

Den kontexten kommer från tillgångshantering, dataklassificering, leverantörsförteckning och riskbedömning.

ISO/IEC 27001:2022 bilaga A kontroll 8.8, Management of technical vulnerabilities, är central, men den fungerar inte ensam. Den är starkt beroende av konfigurationshantering, ändringshantering, leverantörsövervakning, molnstyrning, loggning, övervakning och riskbehandling.

NIST CSF 2.0 uttrycker samma problem i form av utfall. GOVERN-funktionen förväntar sig att rättsliga, regulatoriska och avtalsmässiga cybersäkerhetskrav förstås och hanteras, att riskaptit och risktolerans dokumenteras, att roller och resurser tilldelas samt att cybersäkerhetspolicyer upprättas, tillämpas, granskas och uppdateras. IDENTIFY-utfall omfattar inventeringar av hårdvara, programvara, tjänster, system, data och livscykler, tillsammans med identifiering av sårbarheter, riskanalys, undantagshantering och processer för sårbarhetsrapportering.

I Annas tisdagsmorgonscenario är den första tekniska frågan: “var finns den sårbara komponenten?” Den första styrningsfrågan är: “vilken tjänst och risk påverkar den?”

Zenith Blueprint, riskhanteringsfasen, steg 13: planering av riskbehandling och tillämpbarhetsförklaring, adresserar detta genom att koppla risker till kontroller, ägare och tidsramar:

Tilldela också en ägare och en tidslinje för varje åtgärd (eventuellt i en separat kolumn eller i kommentarerna). T.ex. ”Ägare: IT-chef, tidslinje: senast Q3 2025.” Detta gör det till en faktisk plan.

Det är precis vad åtgärdande av sårbarheter kräver. Ett fynd utan ägare blir brus i backloggen. Ett fynd med ägare, tidslinje, riskbehandlingsbeslut och revisionsspår blir en kontroll som går att granska.

Hur Zenith Controls kartlägger kontrollrelationerna

Zenith Controls behandlar ISO/IEC 27002:2022 kontroll 8.8, Management of technical vulnerabilities, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Den kopplas till cybersäkerhetsbegreppen Identify och Protect, den operativa förmågan hot- och sårbarhetshantering samt säkerhetsdomänerna styrning, ekosystem, skydd och försvar.

Detta är viktigt eftersom SLA för åtgärdande inte bara är en skyddsmekanism. De är också en styrningsmekanism och en ekosystemmekanism. Er exponering formas av leverantörer, molnplattformar, hanterade tjänster, komponenter med öppen källkod och internetexponerade beroenden.

Zenith Controls mappar 8.8 till flera stödjande kontroller:

Zenith Controls kopplar också sårbarhetshantering till ISO/IEC 27005:2024, särskilt identifiering av sårbarheter och riskscenarier som rör opatchade system. Det stärker argumentet att patchningsfrister ska vara riskbaserade, inte godtyckliga. Det kopplar även leverantörsövervakning till ISO/IEC 27036-4:2016 för säkerhetsnivåer i avtal om molntjänster och ISO/IEC 20000-1:2018 för tjänsteleveransplanering och ändringshantering.

Denna standardöverskridande struktur är viktig vid revision. Om en organisation säger “kritiska sårbarheter patchas inom 72 timmar” kommer revisorn att testa om påståendet stöds av riskbedömning, tillgångsklassificering, leverantörsskyldigheter, ändringsunderlag och övervakningsunderlag.

NIS2-cyberhygien: från sårbarhetshantering till korrigerande åtgärder

NIS2 Article 21 kräver en allriskansats för nätverks- och informationssystem. För SLA för åtgärdande av sårbarheter är flera delar av Article 21 direkt relevanta:

• Riskanalys och policyer för informationssystemsäkerhet
• Incidenthantering
• Verksamhetskontinuitet och krishantering
• Säkerhet i leveranskedjan
• Säker anskaffning, utveckling och underhåll, inklusive hantering och rapportering av sårbarheter
• Rutiner för att bedöma cybersäkerhetens effektivitet
• Grundläggande cyberhygien och utbildning
• Åtkomstkontroll och tillgångshantering
• Flerfaktorsautentisering eller kontinuerlig autentisering där det är lämpligt

NIS2 Article 20 gör ledningsorgan ansvariga för att godkänna och övervaka åtgärder för cybersäkerhetsriskhantering. Det innebär att mätetal för åtgärdande av sårbarheter inte enbart kan finnas i en teknisk kontrollpanel. De bör ingå i ledningsrapportering, underlag till riskkommitté eller poster från ledningens genomgång av ISMS.

Article 21 förväntar sig också att enheter som identifierar bristande efterlevnad av föreskrivna åtgärder vidtar korrigerande åtgärder utan onödigt dröjsmål. Den frasen är viktig. Om kontrollpanelen visar försenade kritiska sårbarheter ska efterlevnadsunderlaget inte stanna vid “vi vet”. Det ska visa eskalering, riskgranskning, ledningsinsyn, korrigerande åtgärder och omprövning.

NIS2 Article 23 tillför ytterligare en dimension. Om exploatering av en opatchad sårbarhet orsakar eller kan orsaka allvarlig driftstörning, ekonomisk förlust eller skada för andra personer kan den bli en betydande incident. Rapporteringslivscykeln omfattar tidig varning inom 24 timmar från det att den betydande incidenten blev känd, incidentanmälan inom 72 timmar, mellanliggande rapporter på begäran och en slutrapport inom en månad efter incidentanmälan. Slutrapporten bör omfatta allvarlighetsgrad, påverkan, sannolik rotorsak, riskbegränsande åtgärder och gränsöverskridande påverkan där det är tillämpligt.

SLA-processen ska därför kopplas till incidenthantering. En kritisk sårbarhet med underlag för aktiv exploatering bör utlösa säkerhetstriage, övervakning, bevarande av bevismaterial och en rapporteringsbedömning, inte bara ett rutinmässigt patchärende.

DORA IKT-risk: tidsramar för åtgärdande som resiliensunderlag

För finansiella enheter gäller DORA från den 17 januari 2025 och skapar enhetliga krav för IKT-riskhantering, rapportering av allvarliga IKT-relaterade incidenter, testning av digital operativ resiliens, informationsdelning och hantering av IKT-tredjepartsrisk. Det behandlas som den sektorsspecifika EU-rättsakten för omfattade finansiella enheter som identifieras enligt nationella NIS2-regler.

DORA:s operativa modell ligger nära ett integrerat ISMS. Articles 5 and 6 kräver styrning, policyer, rutiner, verktyg, årlig eller periodisk granskning, revision, åtgärdande av kritiska revisionsiakttagelser och en strategi för digital operativ resiliens. Article 8 kräver identifiering och inventering av IKT-stödda verksamhetsfunktioner, informationstillgångar, IKT-tillgångar, beroenden, tredjepartsprocesser och risker i äldre IKT. Article 9 kräver skyddande och förebyggande kontroller, inklusive patchning och ändringshantering. Articles 11 and 12 kräver kontinuitet, respons, återhämtning, säkerhetskopiering, återställning och återställningsmål.

DORA Articles 17 to 19 kräver en process för hantering av IKT-relaterade incidenter som detekterar, hanterar, registrerar, klassificerar, eskalerar, rapporterar, kommunicerar, analyserar rotorsak och återställer säker drift. Articles 24 to 26 kräver testning av digital operativ resiliens, inklusive lämplig testning av IKT-verktyg och system, sårbarhetsbedömningar, nätverkssäkerhetsbedömningar, gap-analyser, källkodsgranskningar där det är möjligt, penetrationstestning och hotstyrd penetrationstestning för vissa finansiella enheter. Articles 28 and 30 kräver hantering av IKT-tredjepartsrisk, register över IKT-tjänsteavtal, leverantörsgranskning, revisions- och inspektionsrättigheter, servicenivåer, leverantörsstöd vid incidenter, rätt att säga upp avtalet och exitupplägg.

För SLA för åtgärdande förändrar DORA förväntningarna på underlag på tre sätt.

För det första ska sårbarhetsfynd från testning mata in i en prioriterad åtgärdsprocess. En skanningsrapport räcker inte.

För det andra ska åtgärdande av kritiska fynd följas upp genom styrning och revision. DORA förväntar sig formellt åtgärdande av kritiska revisionsiakttagelser för icke-mikroföretag.

För det tredje ska IKT-tredjepartsleverantörer hållas till mätbara skyldigheter. Om er moln-, SaaS- eller MSP-leverantör styr patchningsfönstret ska avtalet och registret visa hur deras tidsramar för åtgärdande stödjer era resiliensskyldigheter.

Policy för sårbarhets- och patchhantering adresserar detta direkt:

Tredjepartspatchning och tillsyn av SaaS-risk 6.6.1 Alla tredjepartssystem (SaaS, PaaS, MSP-hanterade) ska kunna visa ändamålsenliga kontroller för sårbarhetshantering och patchning. 6.6.2 Leverantörs-SLA ska omfatta tidsramar för åtgärdande som motsvarar internt definierade, kritikalitetsbaserade tröskelvärden.

Denna klausul är ofta den saknade bryggan mellan internt ISO-underlag och DORA:s leverantörstillsyn.

GDPR: när patchförseningar blir brister i ansvarsskyldighet för personuppgifter

GDPR är inte en standard för sårbarhetshantering, men den förändrar konsekvenserna av patchfel.

GDPR Article 5 kräver att personuppgifter behandlas säkert och att den personuppgiftsansvarige kan visa efterlevnad. Article 32 kräver lämpliga tekniska och organisatoriska åtgärder för att säkerställa en säkerhetsnivå som är lämplig i förhållande till risken. När opatchade system behandlar personuppgifter, särskilt identitetsdata, finansiella data, biometriska data, hälsodata, anställningsdata eller KYC-information, blir SLA för åtgärdande en del av ansvarsskyldigheten för säkerhet i behandlingen.

En försenad patch kan vara försvarbar om risken bedömdes, kompenserande kontroller tillämpades och kvarstående risk accepterades av rätt person. Den är betydligt svårare att försvara om sårbarheten var försenad, internetexponerad och saknade ägare.

Zenith Controls mappar sårbarhetshantering till GDPR Articles 32 and 5(1)(f), eftersom patchning i rätt tid minskar risker för konfidentialitet och riktighet i personuppgifter. Den mappar också ändringshantering till GDPR Article 24 and Article 32, eftersom ändringar i system som behandlar personuppgifter bör riskbedömas, godkännas, dokumenteras och granskas.

Lärdomen för efterlevnad är tydlig: om personuppgifter berörs ska ert patchunderlag omfatta datakontexten. Revisorer och tillsynsmyndigheter kommer inte bara att fråga “patchades det?” utan även “vilka data exponerades för risk, hur länge och vilka kontroller minskade risken?”

Ett praktiskt Clarysec-arbetsflöde för revisionsklart SLA-underlag

En mogen process för åtgärdande av sårbarheter börjar inte när en revisor ber om poster. Den är utformad för att skapa poster varje månad.

Steg 1: Godkänn SLA-policyn

Börja med Policy för sårbarhets- och patchhantering eller Policy för sårbarhets- och patchhantering – SME, beroende på er operativa modell. Anpassa SLA-trösklar till er riskaptit, regulatoriska omfattning, tjänstekritikalitet, datakänslighet och tekniska begränsningar. Säkerställ godkännande från CISO, riskkommitté eller ledningsorgan.

För enterprise-miljöer används CVSS, tillgångskritikalitet, exploaterbarhet, internetexponering, datakänslighet och verksamhetspåverkan. För SME:er hålls modellen enkel men tydlig: kritiska patchar inom tre dagar, övriga patchar inom 30 dagar om inget giltigt undantag finns.

Steg 2: Mappa tillgångar till ägare och kritiska tjänster

Varje sårbarhetsfynd bör kunna härledas till:

• Tillgångsnamn och unik identifierare
• Verksamhetstjänst eller applikation
• Systemägare
• Teknisk ägare
• Dataklassificering
• Internetexponering
• Leverantörsberoende, om tillämpligt
• Kritikalitet för den funktion som stöds

Detta stödjer riskägarskap enligt ISO/IEC 27001:2022, NIS2-tillgångshantering, DORA-förteckning över IKT-tillgångar och beroenden samt NIST CSF IDENTIFY-utfall.

Steg 3: Triagera sårbarheten

Skapa ett ärende för varje fynd eller grupperad uppsättning fynd. Inkludera CVSS-poäng, källskanner, berörd tillgång, exploateringsstatus, hotinformation, verksamhetskritikalitet och obligatoriskt SLA. Om exploatering misstänks ska ärendet kopplas till en incidentbedömning.

Steg 4: Genomför via ändringshantering

Patchning är en ändring. Använd standardändring för rutinmässiga uppdateringar och akut ändring för kritiska exploaterade sårbarheter. Inkludera testunderlag, godkännande, tidsstämpel för genomförande, rollback-plan och validering efter ändring.

Detta motsvarar relationen i Zenith Controls mellan 8.8 och 8.32, där installation av patchar styrs genom ändringshantering för att balansera brådska och operativ stabilitet.

Steg 5: Validera stängning

Stäng inte ärenden enbart baserat på “patch installerad”. Kräv validering genom omskanning, versionsbekräftelse, konfigurationsverifiering eller bekräftelse av kompenserande kontroller. Om patchen inte kan installeras ska ett undantag öppnas.

Steg 6: Registrera undantag och kvarstående risk

Policy för sårbarhets- och patchhantering definierar obligatoriskt innehåll i undantag:

Undantagsbegäranden ska innehålla: 7.2.1 Verksamhetsmässig motivering för förseningen eller uteblivet åtgärdande 7.2.2 Riskbedömning (baserad på CVSS, tillgångskritikalitet, hotinformation) 7.2.3 Föreslagna kompenserande kontroller 7.2.4 Tidslinje för åtgärdande eller omprövning

Den definierar även godkännande och granskning:

Undantag ska godkännas av CISO eller delegerad riskkommitté och registreras i ISMS-undantagsregister, med ett granskningsintervall som inte överstiger 90 dagar.

Detta undantagsregister blir väsentligt underlag för riskbehandling och acceptans av kvarstående risk enligt ISO/IEC 27001:2022 klausul 6.1.3 samt för ledningens genomgång.

Denna post visar att organisationen inte ignorerade sårbarheten. Den bedömde risken, tillämpade kompenserande kontroller, godkände kvarstående risk och fastställde ett granskningsdatum.

Steg 7: Bygg det månatliga underlagspaketet

Ert månatliga underlagspaket för åtgärdande av sårbarheter bör omfatta:

För SME:er kan underlaget vara lättare, men det måste fortfarande vara konsekvent. Policy för sårbarhets- och patchhantering – SME kräver patchloggar med spårbarhet:

Loggar ska omfatta enhetsnamn, installerad uppdatering, patchningsdatum och skäl för eventuell försening

Den enda klausulen är guld vid revision. Den omvandlar patchning från ett påstående till en post.

Leverantörspatchning: avtalet måste matcha ert SLA

Om en MSP, SaaS-leverantör, PaaS-leverantör eller molntjänstleverantör styr patchdriftsättning är interna SLA verkningslösa om leverantörsskyldigheterna inte motsvarar dem.

Policy för leverantörssäkerhet och tredjepartssäkerhet – SME innehåller informationssäkerhetsskyldigheter som ett styrningskrav. För åtgärdande av sårbarheter bör dessa skyldigheter bli mätbart avtalsspråk:

• Aviseringsfönster för kritiska sårbarheter
• Tidsramar för åtgärdande av kritiska, höga, medelhöga och låga sårbarheter
• Process för akut ändring
• Krav på kundgodkännande vid avbrott
• Underlagsformat för slutförd patchning
• Process för sårbarhetsrapportering
• Skyldigheter att bistå vid incidenter
• Revisionsrätt eller rätt att få försäkransrapporter
• Patchskyldigheter för underbiträden eller underleverantörer
• Exit- och övergångsstöd för kritiska tjänster

Zenith Blueprint, fasen Controls in Action, steg 20, kontroll 8.21 Säkerhet för nätverkstjänster, anger principen tydligt:

När tjänster tillhandahålls externt, inklusive av ISP:er, SD-WAN-leverantörer eller privata molnleverantörer, ska säkerhetskrav byggas in i avtal och SLA:er. Detta omfattar tillgänglighetsgarantier, svarstider för incidenter, skyldigheter att patcha eller mildra sårbarheter och tydliga gränser för datahantering. Du bör aldrig anta att en leverantör uppfyller dina förväntningar om det inte är skriftligt, mätbart och möjligt att granska.

DORA gör detta särskilt viktigt för finansiella enheter. IKT-tredjepartsarrangemang ska omfatta servicenivåer, leverantörsstöd vid IKT-incidenter, åtkomst till och återställning av data, samarbete med myndigheter, rätt att säga upp avtalet och starkare bestämmelser för kritiska eller viktiga funktioner, inklusive övervakning, revisionsrättigheter, beredskapsplaner och säkerhetsåtgärder.

NIST CSF 2.0 säger samma sak genom utfall för leveranskedjerisk: leverantörer bör vara kända, prioriterade efter kritikalitet, bedömda före engagemang, styrda genom avtalskrav, övervakade under hela relationen, inkluderade i incidentplanering och hanterade vid avslut.

Vad revisorer faktiskt kommer att fråga

Revisionsdialogen förändras beroende på revisorns bakgrund.

En ISO/IEC 27001:2022-revisor börjar med ISMS. Revisorn kontrollerar om sårbarhetshantering ingår i tillämpbarhetsförklaringen, om riskbedömningen identifierar opatchade system som en risk, om riskbehandlingsplaner har ägare och tidsramar, om bilaga A kontroll 8.8 är införd, om underlag bevaras och om internrevision och ledningens genomgång utvärderar prestationen.

Zenith Blueprint, fasen Controls in Action, steg 19, gör revisionsförväntningen tydlig:

Detta är en högt prioriterad kontroll för revisorer, och de kommer vanligtvis att gå på djupet. Förvänta dig frågor om hur ofta system patchas, vilken process ni följer när en zero-day offentliggörs och vilka system som är svårast att patcha.

Den fortsätter med praktiska förväntningar på underlag:

Revisorer kommer sannolikt att begära resultat från sårbarhetsskanningar. Om ni använder verktyg som Nessus, OpenVAS eller Qualys, exportera en rapport som visar nyligen upptäckta sårbarheter och hur de hanterades. Helst ska detta omfatta riskklassningar (CVSS) och tidsramar för åtgärdande.

En NIS2-inriktad revisor eller behörig myndighet kommer att leta efter styrelsegodkännande, proportionalitet, cyberhygien, sårbarhetshantering, leverantörssäkerhet, incidenthantering, effektivitetsbedömning, korrigerande åtgärder utan onödigt dröjsmål och beslutsunderlag för rapportering om exploatering orsakade betydande påverkan.

En DORA-tillsynsmyndighet kommer att testa om sårbarhetsfynd är integrerade i IKT-riskhantering, testning av digital operativ resiliens, incidentklassificering, rotorsaksanalys, tredjepartsregister, avtalsförpliktelser, revisionsrättigheter och åtgärdande av kritiska fynd.

En NIST CSF-bedömare kommer sannolikt att strukturera granskningen kring GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER. De kommer att fråga om rättsliga och avtalsmässiga krav förstås, om risktolerans är dokumenterad, om sårbarheter identifieras och prioriteras, om undantag hanteras, om övervakning upptäcker exploatering och om respons- och återställningsåtgärder samordnas.

En COBIT 2019- eller ISACA-liknande revisor fokuserar på styrningsmål, processförmåga, ledningspraxis, mätetal, ägarskap, kontrolldesign, kontrollens funktion och tillräckligt underlag. De kommer att fråga om åtgärdande av sårbarheter är repeterbart, mätt, eskalerat, förbättrat och anpassat till organisationens mål och riskaptit.

Eskalering och mätetal: hur man bevisar att SLA:t hanteras

Ett SLA utan eskalering är bara ett mål. Ett försvarbart program för åtgärdande av sårbarheter behöver eskalering före överskridande, vid överskridande och efter upprepade misslyckanden.

Clarysec rekommenderar en eskaleringsmodell i fyra nivåer:

1. Operativ eskalering, ärendeägare och teknisk ansvarig underrättas innan överskridande.
2. Riskeskalering, tillgångsägare och riskägare granskar påverkan när överskridande är sannolikt.
3. Eskalering till säkerhetsstyrning, CISO eller riskkommitté godkänner undantag eller akut åtgärd.
4. Ledningseskalering, upprepade eller kritiska SLA-överskridanden rapporteras till ledningens genomgång med korrigerande åtgärder.

Policy för sårbarhets- och patchhantering förstärker denna revisionsförväntning:

Periodiska revisioner ska genomföras av Internrevision eller en oberoende tredje part för att verifiera: 5.6.1 Efterlevnad av SLA:er 5.6.2 Underlag för riskbaserad prioritering 5.6.3 Effektivitet hos installerade patchar 5.6.4 Kontroller över opatchade system

Mätetal ska stödja beslut, inte dekorera kontrollpaneler. De starkaste mätetalen för 2026 omfattar:

• Efterlevnadsgrad för kritiska SLA
• Efterlevnadsgrad för höga SLA
• Genomsnittlig tid till triage
• Genomsnittlig tid till åtgärdande per tillgångsklass
• Antal försenade kritiska sårbarheter
• Antal accepterade undantag per ålder
• Undantag som överstiger 90 dagar
• Antal kritiska internetexponerade exponeringar
• SLA-överträdelser hos leverantörer
• Sårbarheter som återöppnats efter validering
• Akuta ändringar orsakade av exploaterade sårbarheter
• Patchfel per plattform eller affärsenhet

Koppla dessa mätetal till ISO/IEC 27001:2022 klausul 9.3 ledningens genomgång, DORA-styrningsrapportering och NIS2-ledningstillsyn. För NIST CSF 2.0 används de för att uppdatera Current och Target Profiles, gap-analys och åtgärdsplaner.

Clarysecs checklista för SLA för åtgärdande

Använd denna checklista för att utvärdera ert nuvarande program:

• Finns det en godkänd policy för sårbarhets- och patchhantering?
• Är SLA för åtgärdande definierade efter allvarlighetsgrad och verksamhetskritikalitet?
• Prioriteras internetexponerade och exploaterade sårbarheter för snabbare åtgärd?
• Är tillgångar mappade till ägare, tjänster, data och leverantörer?
• Omvandlas skannerfynd till tilldelade ärenden?
• Genomförs patchar via ändringshantering?
• Dokumenteras och granskas akuta ändringar?
• Valideras åtgärdsresultat genom omskanningar eller versionskontroller?
• Riskbedöms, godkänns och granskas undantag minst var 90:e dag?
• Dokumenteras kompenserande kontroller för opatchbara system?
• Är leverantörsavtal anpassade till interna tröskelvärden för åtgärdande?
• Är patchloggar tillräckligt kompletta för att bevisa vad som hände och när?
• Eskaleras och korrigeras SLA-överskridanden?
• Granskas mätetal av ledningen?
• Utlöses incidentbedömning när exploatering misstänks?

Om flera svar är “nej” är problemet inte verktygen. Det är kontrolldesignen.

Nästa steg: omvandla patchfrister till revisionsklar resiliens

SLA för åtgärdande av sårbarheter under 2026 måste göra mer än att tillfredsställa en skannerpanel. De måste visa att organisationen kan identifiera exponering, prioritera risk, agera inom godkända tidsramar, styra undantag, styra leverantörer och belägga beslut enligt revisionsförväntningar i ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT 2019.

Clarysec kan hjälpa er att gå från fragmenterade patchärenden till ett integrerat, underlagsdrivet program för åtgärdande av sårbarheter med hjälp av:

• Policy för sårbarhets- och patchhantering
• Policy för sårbarhets- och patchhantering – SME
• Policy för leverantörssäkerhet och tredjepartssäkerhet – SME
• Zenith Blueprint: En revisors färdplan i 30 steg
• Zenith Controls: Guiden för tvärgående regelefterlevnad

Börja med en högrisktjänst. Mappa dess tillgångar, leverantörer, sårbarheter, ärenden, ändringar, undantag och underlag. Kör sedan revisionsfrågorna mot den. Om ni inte kan bevisa SLA:t från detektion till stängning är det ert första åtgärdsprojekt.

Målet är inte perfekt patchning. Målet är styrt, riskbaserat, mätbart och granskningsbart åtgärdande. Ladda ned Clarysecs policymallar, genomför en riktad gap-bedömning eller boka en Clarysec-demo för att omvandla åtgärdande av sårbarheter från revisionstryck till operativ resiliens.